Back to Programming techniques
In this article I present two problems in using unsigned integers in a program. These are the zero boundary problem, and the extended positive range problem.
Most of the time we are assuming that, away from boundaries caused by the finite representation, an integer object works like an element of the integer ring . In addition, it seems plausible that most integer calculations are concentrated around a neighborhood of zero.
The zero-boundary problem (of unsigned integers) is that the zero is on the boundary beyond which the assumption of working with integers falls apart. Thus, the probability of introducing errors in computations increases greatly. Furthermore, those errors can not be catched, since every value is legal.
Looping over values from n to zero backwards demonstrates the zero boundary problem with unsigned integers:
for (unsigned int i = n;i >= 0;--i)
{
// Do something.
}
Since there are no negative values to fail the loop test, this loop never finishes. In contrast, with signed integers the problem does not exist, since the boundaries are located far away from zero:
for (int i = n;i >= 0;--i)
{
// Do something.
}
Conversion between an unsigned integer and a signed integer is an information destroying process in either direction. The only way to avoid this is to use one or the other consistently.
If the normal arithmetic is the intention, then a signed integer represents a more general concept than an unsigned integer: the former covers both the negative and positive integers, whereas the latter only covers non-negative integers. In programming terms, it is possible to create a program using signed integers alone, however, the same can’t be said about the unsigned integers. Therefore, if only one type is to be used consistently, the choice should be a signed integer. However, let us do some more analysis.
Since any non-trivial program must use signed integers, the use of
unsigned integers eventually leads to an unsigned-signed
conversion. In particular, because std::size_t in the Standard
Library is an unsigned integer, there are few programs that can
escape the unsigned-signed conversions.
Despite these conversions, programs still seem to work. The reason for this, I reflect, is that the unsigned integers are normally not taken into the extended positive range they allow. The extended positive range problem is that if the unsigned integers are taken to their extended positive range, then the signed-unsigned conversions become a reality. Ensuring correctness under such a threat is hard, if not practically impossible.
Using unsigned integers to model integers decreases the probability of program being correct.