Search code examples
c++ccompiler-constructionunsigned

What does the unary operator "-" do on unsigned data types in C/C++ (and on different compilers)?

For example:

unsigned int numA = 66; // or anything really
unsigned int numB = -numA;
unsigned int numC = numA & numB

I understand that the bitwise complement operator can be used to get the two's complement (in conjunction with a +1).

The reason I ask is because I stumbled upon this in some code for a chess engine. Chess engines do a lot of 'hacky' things to get absolute speed, especially in the move generation functions that are called millions of times per second. (It doesn't help that it was an example of magic bitboard move generation - the most optimized of them all). This chess engine code in particular only works correctly under gcc compilation (I suspect).

How do different compilers treat this? In particular, how does gcc handle this compared to the C++ compiler in VS Studio 2012 Express.

Thanks.

Solution

  • The relevant quote from the Standard is actually this:

    (§5.3.1/8) The operand of the unary - operator shall have arithmetic or unscoped enumeration type and the result is the negation of its operand. Integral promotion is performed on integral or enumeration operands. The negative of an unsigned quantity is computed by subtracting its value from 2n, where n is the number of bits in the promoted operand. The type of the result is the type of the promoted operand.

    (This is from C++11; it used to be 5.3.1/7 in older versions.)

    So -num will be evaluated as 2CHAR_BIT*sizeof(num) - num (‡). The result will be of the same type as the operand (after integer promotion), i.e. it will also be unsigned.

    I just tested with GCC and it seems to perform the operation in precisely the way described by the Standard. I'll assume this is the case for Visual C++ as well; otherwise it's a bug.

    (‡) This formula assumes that the relevant number of bits corresponds to the size (in bits) of the variable in memory. As Keith Thompson points out in the comment, this can't be true if there are padding bits (i.e. when not all bits participate in the representation of the numerical value, which is possible according to §3.9.1/1). On a system that uses more bits to store the value than are used to represent the numerical value, the formula will not be accurate. (I, personally, am not actually aware of any such system, though.)