Unsigned integers

In the previous lesson (4.4 -- Signed integers), we covered signed integers, which are a set of types that can hold positive and negative whole numbers, including 0.

C++ also supports unsigned integers. Unsigned integers are integers that can only hold non-negative whole numbers.

Defining unsigned integers

To define an unsigned integer, we use the *unsigned* keyword. By convention, this is placed before the type:

1 2 3 4 |
unsigned short us; unsigned int ui; unsigned long ul; unsigned long long ull; |

Unsigned integer range

A 1-byte unsigned integer has a range of 0 to 255. Compare this to the 1-byte signed integer range of -128 to 127. Both can store 256 different values, but signed integers use half of their range for negative numbers, whereas unsigned integers can store positive numbers that are twice as large.

Here’s a table showing the range for unsigned integers:

Size/Type | Range |
---|---|

1 byte unsigned | 0 to 255 |

2 byte unsigned | 0 to 65,535 |

4 byte unsigned | 0 to 4,294,967,295 |

8 byte unsigned | 0 to 18,446,744,073,709,551,615 |

An n-bit unsigned variable has a range of 0 to (2^{n})-1.

Remembering the terms signed and unsigned

New programmers sometimes get signed and unsigned mixed up. The following is a simple way to remember the difference: in order to differentiate negative numbers from positive ones, we use a negative sign. If a sign is not provided, we assume a number is positive. Consequently, an integer with a sign (a signed integer) can tell the difference between positive and negative. An integer without a sign (an unsigned integer) assumes all values are positive.

Unsigned integer overflow

Trick question: What happens if we try to store the number 280 (which requires 9 bits to represent) in a 1-byte unsigned integer? You might think the answer is “overflow!”. But, it’s not.

By definition, unsigned integers cannot overflow. Instead, if a value is out of range, it is divided by one greater than the largest number of the type, and only the remainder kept.

The number 280 is too big to fit in our 1-byte range of 0 to 255. 1 greater than the largest number of the type is 256. Therefore, we divide 280 by 256, getting 1 remainder 24. The remainder of 24 is what is stored.

Here’s another way to think about the same thing. Any number bigger than the largest number representable by the type simply “wraps around” (sometimes called “modulo wrapping”). 255 is in range of a 1-byte integer, so 255 is fine. 256, however, is outside the range, so it wraps around to the value 0. 257 wraps around to the value 1. 280 wraps around to the value 24.

Let’s take a look at this using 2-byte integers:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
#include <iostream> int main() { unsigned short x = 65535; // largest 16-bit unsigned value possible std::cout << "x was: " << x << '\n'; x = 65536; // 65536 is out of our range, so we get wrap-around std::cout << "x is now: " << x << '\n'; x = 65537; // 65537 is out of our range, so we get wrap-around std::cout << "x is now: " << x << '\n'; return 0; } |

What do you think the result of this program will be?

x was: 65535 x is now: 0 x is now: 1

It’s possible to wrap around the other direction as well. 0 is representable in a 1-byte integer, so that’s fine. -1 is not representable, so it wraps around to the top of the range, producing the value 255. -2 wraps around to 254. And so forth.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
#include <iostream> int main() { unsigned short x = 0; // smallest 2-byte unsigned value possible std::cout << "x was: " << x << std::endl; x = -1; // -1 is out of our range, so we get wrap-around std::cout << "x is now: " << x << std::endl; x = -2; // -2 is out of our range, so we get wrap-around std::cout << "x is now: " << x << std::endl; return 0; } |

x was: 0 x is now: 65535 x is now: 65534

Author's note

In common language, unsigned integer wrap around is sometimes incorrectly called “overflow” since the cause is identical to signed integer overflow.

As an aside...

Many notable bugs in video game history happened due to wrap around behavior with unsigned integers. In the arcade game Donkey Kong, it’s not possible to go past level 22 due to an bug that leaves the user with not enough bonus time to complete the level. In the PC game Civilization, Gandhi was known for being the first one to use nuclear weapons, which seems contrary to his normally passive nature. Gandhi’s aggression setting was normally set at 1, but if he went democratic, he’d get a -2 modifier. This wrapped around his aggression setting to 255, making him maximally aggressive!

The controversy over unsigned numbers

Many developers (and some large development houses, such as Google) believe that developers should generally avoid unsigned integers.

This is largely because of two behaviors that can cause problems.

First, consider the subtraction of two unsigned numbers, such as 3 and 5. 3 minus 5 is -2, but -2 isn’t representable as an unsigned number.

1 2 3 4 5 6 7 8 9 10 |
#include <iostream> int main() { unsigned int x = 3; unsigned int y = 5; std::cout << x - y << '\n'; return 0; } |

On the author’s machine, this seemingly innocent looking program produces the result:

1 |
4294967294 |

The occurs due to -2 wrapping around to a number close to the top of the range of a 4-byte integer.

Second, unexpected behavior can result when you mix signed and unsigned integers. In the above example, even if one of the operands (x or y) is signed, the same behavior will result!

Consider the following snippet:

1 2 3 4 5 6 7 8 9 |
void doSomething(unsigned int x) { // Run some code x times } int main() { doSomething(-1); } |

The author of doSomething() was expecting someone to call this function with only positive numbers. But the caller is passing in *-1*. What happens in this case?

The signed argument of *-1* gets implicitly converted to an unsigned parameter. -1 isn’t in the range of an unsigned number, so it wraps around to some large number (probably 4294967295). Then your program goes ballistic. Worse, there’s no good way to guard against this condition from happening. C++ will freely convert between signed and unsigned numbers, but it won’t do any range checking to make sure you don’t overflow your type.

Many modern programming languages (such as Java and C#) either don’t include unsigned types, or limit their use.

New programmers often use unsigned integers to represent non-negative data, or to take advantage of the additional range. Bjarne Stroustrup, the designer of C++, said, “Using an unsigned instead of an int to gain one more bit to represent positive integers is almost never a good idea”.

Unfortunately, due to some poor design choices in the C++ standard library, completely avoiding unsigned numbers in C++ isn’t possible at this point in time.

Warning

Avoid unsigned numbers whenever possible. Don’t avoid negative numbers by using unsigned types. If you need a larger range, use a larger signed type.

If you do use unsigned numbers, take care not to mix signed and unsigned numbers.

4.6 -- Fixed-width integers and size_t |

Index |

4.4 -- Signed integers |

To prevent a overflow you could use the brackets for example int name{ value }. Corrrect?

Brace initialization prevents narrowing casts (Loss of precision), but can't prevent overflows.

oh...... thanks for responding

My question is regarding this. it is mentioned above that "The signed argument of -1 gets implicitly converted to an unsigned parameter". shouldn't that be 1 then

No. The bits stay the same, only the interpretation changes, causing an underflow to probably `4294967295`.

This will make more sense after your read lesson O.3.7 about binary-decimal conversion.

result: -1 why i have this result?

by changing datatyp to

uint16_t x = 1;

int16_t y = -1;

it will work

Signed types get converted to unsigned when compared to unsigned. You should've gotten a compiler warning for your code.

i understad, the compiler will make Implicit integer type conversion, but why it works for 16 bit and it shows -1<+1 and not for 32 bit? and what about using 8 bit ?

ih should be the same,because in all cases will convert from signed tpye to unsigned ?

Sorry, I missed that.

Integral types smaller than int will be promoted to an int when used in arithmetic or comparison.

On your system, a signed int can store the maximum number of a uint16, so promotion to signed int is used (If your int was too small, the uint16 would've been promoted to unsigned int).

You're left with a comparison of 2 signed ints.

280 is 0000 0001 0001 1000 on 16 bits

But on 8 bit, only last 8 bits are stored, 0001 1000, aka 24

So, still it looks like overflow to me. I want to see that definition that says why it is not overflow an why. Keeping 24 is as a (useless) 'random' value as in other cases of overflow.

From C11 6.2.5/9: "The range of nonnegative values of a signed integer type is a subrange of the corresponding unsigned integer type, and the representation of the same value in each type is the same. A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type."

Trying to compile this code gives me the following errors:

C2220 warning treated as error - no 'object' file generated (line 8)

C4305 '=': truncation from 'int' to 'unsigned short' (line 8)

C4309 '=': truncation of constant value (line 8)

error C4305 and C4309 are the same for line 11, what does this error/warning mean?

The comments in the code already say what the error means.

65536 and 65537 don't fit into an unsigned short. The largest value you can store in an unsigned short is 65535.

The value of @x after line 8/11 is 0/1, I'm not sure if these values are well defined. Since you wouldn't expect a different value to be assigned than you wrote, you get a warning. You're compiler is treating warnings as errors, so you get an error.

Clear as day, thanks for clarifying.

Not sure if it's a small typo in the comment under Unsigned integer overflow line 11. Should it be 65537 instead?

Yup. Thanks for pointing that out!

You have a syntactic error in your first program. Line 6.

std::cout << "x was: " << x << '\n'

You need a semicolon there.

Correct indeed. Fixed!

In paragraph 2: C++ also *supposed* unsigned ... should be supports?

Last paragraph before red box: Unfortunately, *do* to ... should be due to.

Thanks! Clearly my proofreading skills leave something to be desired. :)

It is a pleasure. At least you are one of the few people who are still worrying about correct spelling and grammar. That's much appreciated by me, because I hate to have to decipher incorrect spelling and grammar and then still not be sure if I guessed the correct possibility. I know you won't mind if I point out errors, so I do that with pleasure. ;-)

I really do appreciate it. It helps make the site better for everyone.

If I type in "65" it outputs a "6" instead of an "A". Is this undefined behaviour or is there something behind? This did only occur when the user inputs a number.

@std::cin and @std::cout treat @std::int8_t as a char. Your code is no different than if @myInt was a char.