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++.
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.
int would pose no such difficulty, however (since any computations will promote to int); I have nothing good to say about the lack of an unsigned-byte type.
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... ;-)
++ when incrementing, despite the fact that its particular behaviour is rarely needed and might even lead to pointless churning over copies if the loop index is an iterator or other non-fundamental type (or the compiler is really dense).
Sep 16, 2018 at 10:02
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).
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.
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".
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.
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.
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.
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.
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.
size_t is unsigned and ptrdiff_t is signed.
I use unsigned ints to make my code and its intent more clear. One thing I do to guard against unexpected implicit conversions when doing arithmetic with both signed and unsigned types is to use an unsigned short (2 bytes usually) for my unsigned variables. This is effective for a couple reasons:
The general principle is that the type of your unsigned variables should have a lower rank than the type of the signed variables in order to ensure promotion to the signed type. Then you won't have any unexpected overflow behavior. Obviously you can't ensure this all the time, but (most) often it's feasible to ensure this.
For example, recently I had some for loop something like this:
const unsigned short cuint = 5;
for(unsigned short i=0; i<10; ++i)
{
if((i-2)%cuint == 0)
{
//Do something
}
}
The literal '2' is of type int. If i was an unsigned int instead of an unsigned short, then in the sub-expression (i-2), 2 would be promoted to an unsigned int (since unsigned int has a higher priority than signed int). If i = 0, then the sub-expression equals (0u-2u) = some massive value due to overflow. Same idea with i = 1. However, since i is an unsigned short, it gets promoted to the same type as literal '2', which is signed int, and everything works fine.
For added safety: in the rare case where the architecture you're implementing on causes int to be 2 bytes, this might cause both operands in the arithmetic expression to be promoted to unsigned int in the case where the unsigned short variable doesn't fit into the signed 2-byte int, the latter of which has a max value of 32,767 < 65,535. (See https://stackoverflow.com/questions/17832815/c-implicit-conversion-signed-unsigned for more details). To guard against this you can simply add a static_assert to your program as follows:
static_assert(sizeof(int) == 4, "int must be 4 bytes");
and it won't compile on architectures where int is 2 bytes.
for(unsigned int n = 10; n >= 0; n --)(loops infinitely)