What are the best practices regarding unsigned ints?

Question

I use unsigned ints everywhere, and I'm not sure if I should. This can be from database primary key id columns to counters, etc. If a number should never be negative, then I will always used an unsigned int.

However I notice from other's code that no one else seems to do this. Is there something crucial that I'm overlooking?

Edit: Since this question I've also noticed that in C, returning negative values for errors is commonplace rather than throwing exceptions as in C++.

Answer 1

Is there something crucial that I'm overlooking?

When calculations involve both signed and unsigned types as well as different sizes, the rules for type promotion can be complex and lead to unexpected behaviour.

I believe this is the main reason why Java omitted unsigned int types.

Answer 2

I think that Michael has a valid point, but IMO the reason why everybody uses int all the time (especially in for int i = 0; i < max, i++) is that we learned it that way. When every single example in a how to learn programming book uses int in a for loop, very few will ever question that practice.

The other reason is that int is 25% shorter than uint, and we are all lazy... ;-)

Answer 3

Encoding range information into types is A Good Thing. It enforces using reasonable numbers at compile time.

Many architectures seem to have specialized instructions for dealing with int -> float conversions. The conversion from unsigned can be slower (a tiny bit).

Answer 4

I use unsigned int in C++ for array indices, mostly, and for any counter which starts from 0. I think it is good to say explicitly "this variable cannot be negative".

Answer 5

Mixing signed and unsigned types can get you into a world of pain. And you can't use all unsigned types because you will encounter things that either have a valid range that includes negative numbers or need a value to indicate an error and -1 is most natural. So the net result is that many programmers use all signed integers types.

Answer 6

You should care about this when you're dealing with an integer that might actually approach or exceed the limits of a signed int. Since the positive maximum of a 32 bit integer is 2,147,483,647 then you should use an unsigned int if you know it will a) never be negative and b) might reach 2,147,483,648. In most cases, including database keys and counters, I will never even approach these kinds of numbers so I don't bother concerning myself with worrying whether the sign bit is used for a numeric value or to indicate the sign.

I would say: use int unless you know you need an unsigned int.

Answer 7

For me types are much about communication. By using explicitly an unsigned int you tell me that signed values are not valid values. This allows me to add some information when reading your code in addition to the variable name. Ideally I a non anonymous type would tell me more, but it gives me more information than if you had used ints everywhere.

Unfortunately not everybody is very conscious about what their code communicates, and that is probably the reason you see ints everywhere even though the values are at least unsigned.

Answer 8

It's a tradeoff between simplicity and reliability. The more bugs that can be caught at compile time, the more reliable the software. Different people and organizations are on different points along that spectrum.

If you ever do any high-reliability programming in Ada, you even use different types for variables like distance in feet vs. distance in meters, and the compiler flags it if you accidentally assign one to the other. That's perfect for programming a guided missile, but overkill (pun intended) if you're validating a web form. There's not necessarily anything wrong with either way as long as it fits the requirements.

Answer 9

I'm inclined to agree with Joel Etherton's reasoning, but come to the opposite conclusion. The way I see it, even if you know that numbers are unlikely to ever approach the limits of a signed type, if you know that negative numbers won't happen, then there is very little reason to use the signed variant of a type.

For the same reason why I have, in a few select instances, used BIGINT (64 bit integer) rather than INTEGER (32-bit integer) in SQL Server tables. The probability that the data would hit the 32-bit limit within any reasonable amount of time is miniscule, but if it happens, the consequences in some situations could be quite devastating. Just be sure to map types between languages properly, or you are going to end up with interesting weirdness really far down the road...

That said, for some things, such as database primary key values, signed or unsigned really doesn't matter, because unless you are manually repairing broken data or something along those lines, you aren't ever dealing with the value directly; it's an identifier, nothing more. In those cases, consistency is probably more important than the exact choice of signedness. Otherwise, you end up with some foreign key columns that are signed and others that are unsigned, with no apparent pattern to it - or that interesting weirdness again.

Answer 10

I would recommend that outside space-constrained data-storage and data-interchange contexts, one should generally use signed types. In most cases where a 32-bit signed integer would too small but a 32-bit unsigned value would suffice for today, it won't be long before the 32-bit unsigned value isn't big enough either.

The primary times one should use unsigned types are when one is either assembling multiple values into a larger one (e.g. converting four bytes to a 32-bit number) or decomposing larger values into smaller ones (e.g. storing a 32-bit number as four bytes), or when one has a quantity which is expected to "roll over" periodically and one needs to deal with it (think of a residential utility meter; most of them have enough digits to ensure that they won't possibly roll over between readings if they're read three times a year, but not enough to ensure they won't roll over within the useful life of the meter). Unsigned types often have enough 'weirdness' that they should only be used in cases where their semantics are necessary.