Why aren't unsigned variables used more often?

Question

It seems that unsigned integers would be useful for method parameters and class members that should never be negative, but I don't see many people writing code that way. I tried it myself and found the need to cast from int to uint somewhat annoying...

Anyhow what are you thoughts on this?

Duplicate

Why is Array Length an Int and not an UInt?

Answer 1

You shouldn't need to manually cast it, I don't think.

Anyway, it's because for most applications, it doesn't matter - the range for either is big enough for most uses.

Answer 2

Using the standard ones probably avoids the casting to unsigned versions. In your code, you can probably maintain the distinction ok, but lots of other inputs and 3rd party libraries wont and thus the casting will just drive people mad!

Answer 3

Unsigned data types are carried over from the old days when memomry was a premium. So now we don't really need them for that purpose. Combine that with casting and they are a little cumbersome.

Answer 4

You're right in that it probably would be better to use uint for things which should never be negative. In practice, though, there's a few reasons against it:

• int is the 'standard' or 'default', it has a lot of inertia behind it.
• You have to use annoying/ugly explicit casts everywhere to get back to int, which you're probably going to need to do a lot due to the first point after all.
• When you do cast back to int, what happens if your uint value is going to overflow it?
• A lot of the time, people use ints for things that are never negative, and then use -1 or -99 or something like that for error codes or uninitialised values. It's a little lazy perhaps, but again this is something that uint is less flexible with.

Answer 5

The idea, that unsigned will prevent you from problems with methods/members that should not have to deal with negative values is somewhat flawed:

• now you have to check for big values ('overflow') in case of error
  • whereas you could have checked for <=0 with signed
• use only one signed int in your methods and you are back to square "signed" :)

Use unsigned when dealing with bits. But don't use bits today anyway, except you have such a lot of them, that they fill some megabytes or at least your small embedded memory.

Answer 6

I can't remember exactly how C# does its implicit conversions, but in C++, widening conversions are done implicitly. Unsigned is considered wider than signed, and so this leads to unexpected problems:

int s = 5;
unsigned int u = 25;
// s > u is false

int s = -1;
unsigned int u = 25;
// s > u is **TRUE**! Error error!

In the example above, s overflowed, so it's value will be something like 4294967295. This has caused me problems before, I often have methods return -1 to say "no match" or something like that, and with the implicit conversion it just fails to do what I think it should.

After a while programmers learnt to almost always use signed variables, except in exceptional cases. Compilers these days also produce warnings for this which is very helpful.

Answer 7

The biggest reason is that people are usually too lazy, or not thinking closely enough, to know where they're appropriate. Something like a size_t can never be negative, so unsigned is correct.

Casting from signed to unsigned can be fraught with peril though, because of peculiarities in how sign bits are handled by the underlying architecture.

Answer 8

One reason is that public methods or properties referring to unsigned types aren't CLS compliant.

You'll almost always see this attribute applied to .Net assemblies as various wizards include it by default:

[assembly: CLSCompliant(true)]

So basically if your assembly includes the attribute above, and you try to use unsigned types in your public interface with the outside world, you'll get a compilation error.

Answer 9

there is no real need. Declaring something as unsigned to say numbers should be positive is a poor mans attempt at validation.

In fact it would be better to just have a single number class that represented all numbers.

To Validate numbers you should use some other technique because generally the constraint isn't just positive numbers, it's a set range. It's usually best to use the most unconstrained method for representing numbers and then if you want to change the rules for allowable values, you change JUST the validation rules NOT the type.

Answer 10

For simplicity. Modern software involves enough casts and conversions. There's a benefit to stick to as few, commonly available data types as possible to reduce complexity and ambiguity about proper interfaces.

Answer 11

It's not advisable to use unsigned integer because if u assigned negative values to it, all hell break lose. However, if you insists on doing it the right way, try using Spec#, declare it as an integer (where you would have used uint) and attach an invariant to it saying it can never be negative.

Answer 12

It is because they are not CLS compliant, which means your code might not run as you expect on other .NET framework implementations or even on other .NET languages (unless supported).

Also it is not interoperable with other systems if you try to pass them. Like a web service to be consumed by Java, or call to Win32 API

See that SO post on the reason why as well