Question

Given the following piece of (pseudo-C++) code:

float x=100, a=0.1;
unsigned int height = 63, width = 63;
unsigned int hw=31;
for (int row=0; row < height; ++row)
{
    for (int col=0; col < width; ++col)
    {
        float foo = x + col - hw + a * (col - hw);
        cout << foo << " ";
    }
    cout << endl;
}

The values of foo are screwed up for half of the array, in places where (col – hw) is negative. I figured because col is int and comes first, that this part of the expression is converted to int and becomes negative. Unfortunately, apparently it doesn’t, I get an overflow of an unsigned value and I’ve no idea why.

How should I resolve this problem? Use casts for the whole or part of the expression? What type of casts (C-style or static_cast<…>)? Is there any overhead to using casts (I need this to work fast!)?

EDIT: I changed all my unsigned ints to regular ones, but I’m still wondering why I got that overflow in this situation.

Answer 1

Unsigned integers implement unsigned arithmetic. Unsigned arithmetic is modulo arithmetics. All values are adjusted modulo 2^N, where N is the number of bits in the value representation of unsigned type.

In simple words, unsigned arithmetic always produces non-negative values. Every time the expression should result in negative value, the value actually “wraps around” 2^N and becomes positive.

When you mix a signed and an unsigned integer in a [sub-]expression, the unsigned arithmetic “wins”, i.e. the calculations are performed in unsigned domain. For example, when you do col - hw, it is interpreted as (unsigned) col - hw. This means that for col == 0 and hs == 31 you will not get -31 as the result. Instead you wil get UINT_MAX - 31 + 1, which is normally a huge positive value.

Having said that, I have to note that in my opinion it is always a good idea to use unsigned types to represent inherently non-negative values. In fact, in practice most (or at least half) of integer variables in C/C++ the program should have unsigned types. Your attempt to use unsigned types in your example is well justified (if understand the intent correctly). Moreover, I’d use unsigned for col and row as well. However, you have to keep in mind the way unsigned arithmetic works (as described above) and write your expressions accordingly. Most of the time, an expression can be rewritten so that it doesn’t cross the bounds of unsigned range, i.e. most of the time there’s no need to explicitly cast anything to signed type. Otherwise, if you do need to work with negative values eventually, a well-placed cast to signed type should solve the problem.