Why prefer signed over unsigned in C++? [closed]

Answer 1

Let me paraphrase the video, as the experts said it succinctly.

Andrei Alexandrescu:

• No simple guideline.
• In systems programming, we need integers of different sizes and signedness.
• Many conversions and arcane rules govern arithmetic (like for auto), so we need to be careful.

Chandler Carruth:

• Here's some simple guidelines:
  1. Use signed integers unless you need two's complement arithmetic or a bit pattern
  2. Use the smallest integer that will suffice.
  3. Otherwise, use int if you think you could count the items, and a 64-bit integer if it's even more than you would want to count.
• Stop worrying and use tools to tell you when you need a different type or size.

Bjarne Stroustrup:

• Use int until you have a reason not to.
• Use unsigned only for bit patterns.
• Never mix signed and unsigned

Wariness about signedness rules aside, my one-sentence take away from the experts:

Use the appropriate type, and when you don't know, use an int until you do know.

Answer 2

1. Use int by default: it plays nicer with the rest of the language

   • most common domain usage is regular arithmetic, not modular arithmetic
   • int main() {} // see an unsigned?
   • auto i = 0; // i is of type int

2. Only use unsigned for modulo arithmetic and bit-twiddling (in particular shifting)

   • has different semantics than regular arithmetic, make sure it is what you want
   • bit-shifting signed types is subtle (see comments by @ChristianRau)
   • if you need a > 2Gb vector on a 32-bit machine, upgrade your OS / hardware

3. Never mix signed and unsigned arithmetic

   • the rules for that are complicated and surprising (either one can be converted to the other, depending on the relative type sizes)
   • turn on -Wconversion -Wsign-conversion -Wsign-promo (gcc is better than Clang here)
   • the Standard Library got it wrong with std::size_t (quote from the GN13 video)
   • use range-for if you can,
   • for(auto i = 0; i < static_cast<int>(v.size()); ++i) if you must

4. Don't use short or large types unless you actually need them

   • current architectures data flow caters well to 32-bit non-pointer data (but note the comment by @BenVoigt about cache effects for smaller types)
   • char and short save space but suffer from integral promotions
   • are you really going to count to over all int64_t?

Answer 3

It gives unexpected result when doing simple arithmetic operation:

unsigned int i;
i = 1 - 2;
//i is now 4294967295 on a 64bit machine

It gives unexpected result when doing simple comparison:

unsigned int j = 1;
std::cout << (j>-1) << std::endl;
//output 0 as false but 1 is greater than -1

This is because when doing the operations above, the signed ints are converted to unsigned, and it overflows and goes to a really big number.

Answer 4

Several reasons:

1. Arithmetic on unsigned always yields unsigned, which can be a problem when subtracting integer quantities that can reasonably result in a negative result — think subtracting money quantities to yield balance, or array indices to yield distance between elements. If the operands are unsigned, you get a perfectly defined, but almost certainly meaningless result, and a result < 0 comparison will always be false (of which modern compilers will fortunately warn you).

2. unsigned has the nasty property of contaminating the arithmetic where it gets mixed with signed integers. So, if you add a signed and unsigned and ask whether the result is greater than zero, you can get bitten, especially when the unsigned integral type is hidden behind a typedef.

Answer 5

One good reason that I can think of is in case of detecting overflow.

For the use cases such as the count of items in an array, length of a string, or size of memory block, you can overflow an unsigned int and you may not notice a difference even when you take a look at the variable. If it is an signed int, the variable will be less than zero and clearly wrong.

You can simply check to see if the variable is zero when you want to use it. This way, you do not have to check for overflow after every arithmetic operation as is the case for unsigned ints.

Answer 6

The int type more closely resembles the behavior of mathematical integers than the unsigned type.

It is naive to prefer the unsigned type simply because a situation does not require negative values to be represented.

The problem is that the unsigned type has a discontinuous behavior right next to zero. Any operation that tries to compute a small negative value, instead produces some large positive value. (Worse: one that is implementation-defined.)

Algebraic relationships such as that a < b implies that a - b < 0 are wrecked in the unsigned domain, even for small values like a = 3 and b = 4.

A descending loop like for (i = max - 1; i >= 0; i--) fails to terminate if i is made unsigned.

Unsigned quirks can cause a problem which will affect code regardless of whether that code expects to be representing only positive quantities.

The virtue of the unsigned types is that certain operations that are not portably defined at the bit level for the signed types are that way for the unsigned types. The unsigned types lack a sign bit, and so shifting and masking through the sign bit isn't a problem. The unsigned types are good for bitmasks, and for code that implements precise arithmetic in a platform-independent way. Unsigned opearations will simulate two's complement semantics even on a non two's complement machine. Writing a multi-precision (bignum) library practically requires arrays of unsigned types to be used for the representation, rather than signed types.

The unsigned types are also suitable in situations in which numbers behave like identifiers and not as arithmetic types. For instance, an IPv4 address can be represented in a 32 bit unsigned type. You wouldn't add together IPv4 addresses.