Advice on unsigned int (Gangnam Style edition)

Question

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-

Answer 1

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 ints. With unsigned ints you must be aware of integer underflow as well, and with doubles and floats 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.

Answer 2

You specific question is:

"Is it bad practice to use unsigned?" to which the only correct answer can be no. It is not bad practice.

There are many style guides, each with a different focus, and while in some cases, an organisation, given their typical toolchain and deployment platform may choose not to use unsigned for their products, other toolchains and platforms almost demand it's use.

Google seem to get a lot of deference because they have a good business model (and probably employ some smart people like everyone else).

CERT IIRC recommend unsigned for buffer indexes, because if you do overflow, at least you'll still be in your own buffer, some intrinsic security there.

What do the language and standard library designers say (probably the best representation of accepted wisdom). strlen returns a size_t, which is probably unsigned (platform dependent), other answers suggest this is an anachronism because shiny new computers have wide architectures, but this misses the point that C and C++ are general programming languages and should scale well on big and small platforms.

Bottom line is that this is one of many religious questions; certainly not settled, and in these cases, I normally go with my religion for green field developments, and go with the existing convention of the codebase for existing work. Consistency matters.

Answer 3

Use the right type for the operations which you will perform. float wouldn't make sense for a counter. Nor does signed int. The normal operations on the counter are print and +=1.

Even if you had some unusual operations, such as printing the difference in viewcounts, you wouldn't necessarily have a problem. Sure, other answers mention the incorrect abs(i2-i1) but it's not unreasonable to expect programmers to use the correct max(i2,i1) - min(i2,i1). Which does have range issues for signed int. No uniform solution here; programmers should understand the properties of the types they're working with.

Answer 4

Google states that: "Some people, including some textbook authors, recommend using unsigned types to represent numbers that are never negative. This is intended as a form of self-documentation."

I personally use unsigned ints as index parameters.

int foo(unsigned int index, int* myArray){
    return myArray[index];
}

Google suggests: "Document that a variable is non-negative using assertions. Don't use an unsigned type."

int foo(int index, int* myArray){
    assert(index >= 0);
    return myArray[index];
}

Pro for Google: If a negative number is passed in debug mode my code will hopefully return an out of bounds error. Google's code is guaranteed to assert.

Pro for me: My code can support a greater size of myArray.

I think the actual deciding factor comes down to, how clean is your code? If you clean up all warnings, it will be clear when the compiler warns you know when you're trying to assign a signed variable to an unsigned variable. If your code already has a bunch of warnings, the compiler's warning is going to be lost on you.

A final note here: Google says: "Sometimes gcc will notice this bug and warn you, but often it will not." I haven't seen that to be the case on Visual Studio, checks against negative numbers and assignments from signed to unsigned are always warned. But if you use gcc you might have a care.

Answer 5

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.