Mfrhtyj

Well, I guess this is an exception to "two wrongs don't make a right" :)

What is happening is that there are actually two wrap arounds (unsigned overflows) under the hood and the final result is ends up being mathematically correct.

• First, i is converted to unsigned and as per wrap around behavior the value is std::numeric_limits<unsigned>::max() - 9.




• When this value is summed with u the mathematical result would be std::numeric_limits<unsigned>::max() - 9 + 42 == std::numeric_limits<unsigned>::max() + 33 which is an overflow and we get another wrap around. So the final result is 32.

As a general rule in an arithmetic expression if you only have unsigned overflows (no matter how many) and if the final mathematical result is representable in the expression data type, then the value of the expression will be the mathematically correct one. This is a consequence of the fact that unsigned integers in C++ obey the laws of arithmetic modulo 2ⁿ (see bellow).

Important notice. According to C++ unsigned arithmetic does not overflow:

§6.9.1 Fundamental types [basic.fundamental]

4. Unsigned integers shall obey the laws of arithmetic modulo 2ⁿ where n
   is the number of bits in the value representation of that particular
   size of integer ⁴⁹
   

49) This implies that unsigned arithmetic does not 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 unsigned integer type.

I will however leave "overflow" in my answer to signify values that cannot be represented in regular arithmetic.

Also what we colloquially call "wrap around" is in fact just the arithmetic modulo nature of the unsigned integers. I will however use "wrap around" also because it is easier to understand.

i is in fact promoted to unsigned int.

Unsigned integers in C and C++ implement arithmetic in ℤ / 2ⁿℤ, where n is the number of bits in the unsigned integer type. Thus we get

[42] + [-10] ≡ [42] + [2ⁿ - 10] ≡ [2ⁿ + 32] ≡ [32],

with [x] denoting the equivalence class of x in ℤ / 2ⁿℤ.

Of course, the intermediate step of picking only non-negative representatives of each equivalence class, while it formally occurs, is not necessary to explain the result; the immediate

[42] + [-10] ≡ [32]

would also be correct.

"In the second expression, the int value -42 is converted to unsigned before the addition is done"

yes this is true

unsigned u = 42;

int i = -10;

std::cout << u + i << std::endl; // Why the result is 32?

Supposing we are in 32 bits (that change nothing in 64b, this is just to explain) this is computed as 42u + ((unsigned) -10) so 42u + 4294967286u and the result is 4294967328u truncated in 32 bits so 32. All was done in unsigned

This is part of what is wonderful about 2's complement representation. The processor doesn't know or care if a number is signed or unsigned, the operations are the same. In both cases, the calculation is correct. It's only how the binary number is interpreted after the fact, when printing, that is actually matters (there may be other cases, as with comparison operators)

-10 in 32BIT binary is FFFFFFF6

42 IN 32bit BINARY is  0000002A

Adding them together, it doesn't matter to the processor if they are signed or unsigned, the result is: 100000020. In 32bit, the 1 at the start will be placed in the overflow register, and in c++ is just disappears. You get 0x20 as the result, which is 32.

In the first case, it is basically the same:

-42 in 32BIT binary is FFFFFFD6

10 IN 32bit binary is 0000000A

Add those together and get FFFFFFE0

FFFFFFE0 as a signed int is -32 (decimal). The calculation is correct! But, because it is being PRINTED as an unsigned, it shows up as 4294967264. It's about interpreting the result.