The video "Gangnam Style" (I'm sure you've heard it) just exceeded 2 billion views on youtube. In fact, Google says that they never expected a video to be greater than a 32-bit integer... which alludes to the fact that Google used int
instead of unsigned
for their view counter. I think they had to re-write their code a bit to accommodate larger views.
Checking their style guide: https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Integer_Types
...they advise "don't use an unsigned integer type," and give one good reason why: unsigned
could be buggy.
It's a good reason, but could be guarded against. My question is: is it bad coding practice in general to use unsigned int
?
Unsigned integers are used when we know that the value that we are storing will always be non-negative (zero or positive).
The Google C++ style guide recommends avoiding unsigned integers except in situations that definitely require it (for example: file formats often store sizes in uint32_t or uint64_t -- no point in wasting a signedness bit that will never be used).
An int is signed by default, meaning it can represent both positive and negative values. An unsigned is an integer that can never be negative.
The data type to declare an unsigned integer is: unsigned int and the format specifier that is used with scanf() and print() for unsigned int type of variable is "%u".
The Google rule is widely accepted in professional circles. The problem is that the unsigned integral types are sort of broken, and have unexpected and unnatural behavior when used for numeric values; they don't work well as a cardinal type. For example, an index into an array may never be negative, but it makes perfect sense to write abs(i1 - i2)
to find the distance between two indices. Which won't work if i1
and i2
have unsigned types.
As a general rule, this particular rule in the Google style guidelines corresponds more or less to what the designers of the language intended. Any time you see something other than int
, you can assume a special reason for it. If it is because of the range, it will be long
or long long
, or even int_least64_t
. Using unsigned types is generally a signal that you're dealing with bits, rather than the numeric value of the variable, or (at least in the case of unsigned char
) that you're dealing with raw memory.
With regards to the "self-documentation" of using an unsigned
: this doesn't hold up, since there are almost always a lot of values that the variable cannot (or should not) take, including many positive ones. C++ doesn't have sub-range types, and the way unsigned
is defined means that it cannot really be used as one either.
This guideline is extremely misleading. Blindly using int
instead of unsigned int
won't solve anything. That simply shifts the problems somewhere else. You absolutely must be aware of integer overflow when doing arithmetic on fixed precision integers. If your code is written in a way that it does not handle integer overflow gracefully for some given inputs, then your code is broken regardless of whether you use signed
or unsigned int
s. With unsigned int
s you must be aware of integer underflow as well, and with double
s and float
s you must be aware of many additional issues with floating point arithmetic.
Just take this article about a bug in the standard Java binary search algorithm published by none other than Google for why you must be aware of integer overflow. In fact, that very article shows C++ code casting to unsigned int
in order to guarantee correct behavior. The article also starts out by presenting a bug in Java where guess what, they don't have unsigned int
. However, they still ran into a bug with integer overflow.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With