95

I have just tried implementing a class where numerous length/count properties, etc. are uint instead of int. However, while doing so I noticed that it's actually painful to do so, like as if no one actually wants to do that.

Nearly everything that hands out an integral type returns an int, therefore requiring casts in several points. I wanted to construct a StringBuffer with its buffer length defaulted to one of the fields in that class. Requires a cast too.

So I wondered whether I should just revert to int here. I'm certainly not using the entire range anyway. I just thought since what I'm dealing with there simply can't be negative (if it was, it'd be an error) it'd be a nice idea to actually use uint.

P.S.: I saw this question and this at least explains why the framework itself always uses int but even in own code it's actually cumbersome to stick to uint which makes me think it apparently isn't really wanted.

Community
  • 1
  • 1
Joey
  • 344,408
  • 85
  • 689
  • 683
  • Also see [why-does-net-use-int-instead-of-uint-in-certain-classes](http://stackoverflow.com/questions/782629/why-does-net-use-int-instead-of-uint-in-certain-classes) – nawfal Jul 15 '14 at 15:40

9 Answers9

67

I'll add to the other answers also that using uint as type of a public field, property, method, parameter, and so on, is a violation of the Common Language Specification rules and to be avoided when possible.

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • 3
    And I got burnt by Microsoft strictly following that. It turns out that IntPtr should have had a uint constructor. – Joshua Jun 03 '10 at 03:49
  • 3
    I would also add if they supported natural numbers eg this type is value 0 to 6 they could eliminate all array bounds checking , a massive 5-10% performance boost . – user1496062 Jul 04 '13 at 03:05
  • Do you concurr with the statement above, Mr. Lippert? – AgentFire May 15 '19 at 15:52
  • @AgentFire: The statement makes a claim that if someone did something, that would cause a specific performance improvement. I have no ability to evaluate counterfactual claims; if you want to know if that claim is true, ask user1496062 what justifies their claim, not me; I'm not the one making the unsupported claim. – Eric Lippert May 15 '19 at 18:16
  • 4
    @EricLippert that's one of your shortest longest "i dont know"s, isnt it :p – AgentFire May 15 '19 at 20:14
44

While strictly you should use uint for variables that hold non-negative integer you have come across one of reasons why it's not always practicable.

In this case I don't think the reduction in readability that comes with having to do casts is worth it.

ChrisF
  • 134,786
  • 31
  • 255
  • 325
  • 2
    Its hard to say , i dont think the casts reduce legability a lot for just indexers and you can create a wrapper. And ints that become negative are painful and expensive bugs. – user1496062 Jul 04 '13 at 03:04
  • 8
    If you have to create a wrapper for an int then you have more than readability problems :) – S.. Jan 22 '14 at 10:40
4

My personal feeling is that you should probably just stick to int. It's not worth adding a cast to pretty much every single property access just to reclaim a numeric range that .NET's unlikely to let you use anyway.

ChrisV
  • 3,363
  • 16
  • 19
4

A negative value is often used to signal an error condition, and the size of a operation is often returned by a function call; a negative value may therefore signal error without resorting to an exception mechanism.

Also note that .NET often builds upon straight C libraries, therefore it is sensible to continue this convention. If you require a larger index space you can break the convention for different error signalling mechanism.

Hassan Syed
  • 20,075
  • 11
  • 87
  • 171
  • 25
    .NET's pretty consistent with throwing exceptions rather than returning error codes. The -1 return is not a common sight in managed code. – ChrisV Jan 06 '10 at 13:32
  • agreed, but we are talking about a design convention that is prevalent throughout windows technologies (in addition to exceptions where they are supported) -- those parts of the .NET library that interface with low level code have to translate between CRT error codes and exceptions -- it is sort of understandable why they bring forward the convention of int's rather than uint's. – Hassan Syed Jan 06 '10 at 13:56
  • @HassanSyed still, if some winapi returns negative value, the framework will still throw it's own exception, wrapping everything into a neat shell, so that argument doesn't rly apply here. – AgentFire May 15 '19 at 15:53
3

Using an int is also helpful to detect integer overflow in operations.

Ioan
  • 2,382
  • 18
  • 32
  • Not 100% accurate, if it so overflowed that it reaches zero. Again, there is a overflow protection enabled by default. – AgentFire May 15 '19 at 15:54
3

IMO, the drawback of using uint is that it obscures error conditions. The equivalents of the following code aren't as nice:

if (len < 0)
    terminate_program("length attained impossible value.");

Of course your programs should not miscalculate anything to begin with, but I feel they also should be written to rapidly detect numerical erros without propagation. In the case where a MaxValue of 2^31 is enough, I say use int along with proper use of System.Diagnostics.Debug.Assert() and corresponding error-checks as exemplified above.

If you do use uint use it along with checked to prevent underflow and get the same results. However I have found that check is a little bit difficult to apply to existing code that uses casts for some purpose.

Heath Hunnicutt
  • 18,667
  • 3
  • 39
  • 62
2

If you want to check that a value is positive, a better way is probably just by using assert (note this is just a debugging technique - you should ensure that this never occurs in the final code).

using System.Diagnostics;
...
Debug.Assert (i > 0);
Joey
  • 344,408
  • 85
  • 689
  • 683
ternaryOperator
  • 833
  • 4
  • 10
2

Don't swim upstream if you don't have to. Not litering your code with casts makes your code more readable. Further, if your possible values fit within an int, then using an int is not a problem.

If you're afraid you might overflow an int, then there by all means.. but don't prematurely optimize.

I would say the improved readability of minimizing casts outweighs the slightly elevated risk of a bug with using int.

Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291
0

i think you should use it only if you wont need to cast from uint to int or the other way around back and forth.

its ok to cast but, if the integer you're casting to uint is a minus value, then casting it to uint will set the uint to the maximum value possible ( 2^32), which could lead into some bugs.

Berkay Deniz
  • 1