unsigned int /有符号int / long long：莫名其妙的输出

Question

So I was playing around with types and I came out with this weird result below. Debugging it made no sense, and then the only result was to check out the c++ spects, which didn't helped much. I was wondering if you might know what is happening here exactly, and if it is 32Bit and/or 64Bit specific issue.

#include <iostream>
using namespace std;

int main() {
    unsigned int u = 1;
    signed int i = 1;

    long long lu = -1 * u;
    long long li = -1 * i;

    std::cout<<"this is a weird " << lu << " " << li << std::endl;

    return 0;
}

Where the output is

this is a weird 4294967295 -1

Answer 1

The key observation is that the expression -1 * u is of type unsigned int . That is because the rules for arithmetic conversions* say that if one operand is unsigned int and the other is signed int , then the latter operand is converted to unsigned int . The arithmetic expressions are ultimately only defined for homogeneous operands, so the conversions happen before the operation proper.

The result of the conversion of -1 to unsigned int is a large, positive number, which is representable as a long long int , and which is the number you see in the output.

_{Currently, that's [expr]/(11.5.3).}

Answer 2

The evaluation of

-1 * i

is trivial multiplication of two int types: nothing strange there. And a long long must be capable of holding any int .

---

First note is there is no such thing as a negative literal in C++, so

-1 * u

is evaluated as (-1) * u due to operator precedence. The type of (-1) must be int . But this will be converted to unsigned int due to C++'s rule of argument conversion as the other argument is an unsigned int In doing that it is converted modulo UINT_MAX + 1 , so you end up with UINT_MAX multiplied by 1, which is the number you observe, albeit converted to a long long type.

As a final note, the behaviour of this conversion is subject to the rules of conversion from an unsigned to a signed type: if unsigned int and long long were both 64 bits on your platform then the behaviour is implementation-defined.

Answer 3

The type of -1 is signed int . When you perform an arithmetic operation between objects of different fundamental type, one or both of the arguments will be converted so that both have the same type. (For non-fundamental types, there may be operator overloads for mixed operands). In this case, the signed value is converted to unsigned, following the conversion rules ^† .

So, -1 was converted to unsigned. But negative numbers cannot be represented by unsigned types. What happens, is that the resulting value will be the smallest positive value that can be represented by the unsigned type, that is congruent with the original signed value modulo the maximum value representable by unsigned type. Which on your platform happens to be 4294967295.

---

^† The rules ([expr], standard draft):

... rules that apply to non-integers ...

Otherwise, the integral promotions (4.5) shall be performed on both operands.61 Then the following rules shall be applied to the promoted operands:

— If both operands have the same type, no further conversion is needed.

— Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank shall be converted to the type of the operand with greater rank.

— Otherwise, if the operand that has unsigned integer type has rank greater than or equal to the rank of the type of the other operand, the operand with signed integer type shall be converted to the type of the operand with unsigned integer type. (this applies to your case)

— Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, the operand with unsigned integer type shall be converted to the type of the operand with signed integer type.

— Otherwise, both operands shall be converted to the unsigned integer type corresponding to the type of the operand with signed integer type.

Answer 4

The bit pattern "0xFFFFFFFF" corresponds with "-1" when interpreted as a 32b signed integer and corresponds with "4294967295" when interpreted as a 32b unsigned integer.

• If used -2 the result is "4294967294"
• If used -3 the result is "4294967293"
• If used -4 the result is "4294967292"
• ....