CODEWITHSUNDEEP
c++
Somebody
Somebody

Reputation: 261

unsigned to signed conversion

Consider the following:

#include <iostream>

int main() {

    unsigned int x = 3;
    unsigned int y = 5;

    std::cout << "a: " << x - y        << std::endl;

    std::cout << "b: " << ((int)x) - y << std::endl;

    std::cout << "c: " << x - ((int)y) << std::endl;

    std::cout << "d: " << ((int)x) - ((int)y) << std::endl;

}

$ g++ -Wconversion -Wall uint_stackoverflow.cc -o uint_stackoverflow && ./uint_stackoverflow
a: 4294967294
b: 4294967294
c: 4294967294
d: -2

I understand why "a" doesn't give the expected result. But why "b" and "c" fail puzzles me. For "b" I thought after casting "x" to "int" the result will be "int" again.

Could you please enlighten me?

edit: Shouldn't the compiler warn? g++ (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5

Thanks,

Somebody

Upvotes: 12

Views: 23565

Answers (3)

Sarfaraz Nawaz
Sarfaraz Nawaz

Reputation: 361732

In arithmetic operations, if any of the operand is unsigned, the other operand converts to unsigned (if its signed), and the result of the operations will be unsigned also.

Also, casting unsigned to signed and then doing the operation doesn't change the bit representation of the operand. On a two's complement architecture (i.e almost every modern architecture), (int)x has same bit representation as x has, only their interpretation changes when calculating their value in decimal system. But the important point is that the arithmetic operation is performed on the bit representations (not on their values in decimal system). And since the casting doesn't change the bit representation, the bit representation of the result will also NOT change.

C++03 Standard says in §5/9:

Many binary operators that expect operands of arithmetic or enumeration type cause conversions and yield result types in a similar way. The purpose is to yield a common type, which is also the type of the result. This pattern is called the usual arithmetic conversions, which are defined as follows:

[...]

Otherwise, if either operand is unsigned, the other shall be converted to unsigned.

Upvotes: 28

kennytm
kennytm

Reputation: 523694

Quoting the standard as usual....

For C++98, §[expr]/9:

Many binary operators that expect operands of arithmetic or enumeration type cause conversions and yield result types in a similar way. The purpose is to yield a common type, which is also the type of the result. This pattern is called the usual arithmetic conversions, which are defined as follows:

  • If either operand is of type long double, the other shall be converted to long double.
  • Otherwise, if either operand is double, the other shall be converted to double.
  • Otherwise, if either operand is float, the other shall be converted to float.
  • Otherwise, the integral promotions (4.5) shall be performed on both operands.54)
  • Then, if either operand is unsigned long the other shall be converted to unsigned long.
  • Otherwise, if one operand is a long int and the other unsigned int, then if a long int can represent all the values of an unsigned int, the unsigned int shall be converted to a long int; otherwise both operands shall be converted to unsigned long int.
  • Otherwise, if either operand is long, the other shall be converted to long.
  • Otherwise, if either operand is unsigned, the other shall be converted to unsigned.

[Note: otherwise, the only remaining case is that both operands are int ]

Basically, it can be summarized as

  • long double > double > float > unsigned long > long > unsigned > int
  • (Types smaller than int will be converted to int)

The text is changed for C++0x (§[expr]/10) after the 5th item, but the effect on OP's code is the same: the int will be converted to an unsigned.

Upvotes: 12

daz-fuller
daz-fuller

Reputation: 1231

It's because there is a heirarchy of data types when performing implicit conversions, unsigned integers have a higher precedence than signed integers so b and c are being cast back to unsigned integers which is why you're seeing the results you are.

If you are unsure of the types but know the type of the result you want then you should cast both x and y as you did in d.

This has a really good explanation of type conversion:

http://www.learncpp.com/cpp-tutorial/44-type-conversion-and-casting/

Upvotes: 3

Related Questions