13

I have the following piece of code:

#include <cstdint>

template <typename T>
T test(T a, T b)
{
    float aabb = reinterpret_cast<float>(a - b);
}

int main(int argc, const char *argv[])
{
    std::uint8_t a8, b8;
    test(a8, b8);
    return 0;
}

I know that the reinterpret_cast<float> can't work and that it gives an error at compile time. I am using that error so that the compiler tells me the type of a - b.

The problem is that in this case, it says that the type of a - b is int when both of them are uint8_t (unsigned char). The same happens with uint16_t. But not with uint32_t which it says that a - b is unsigned int.

So, my question is: Is this intended behaviour (that unsigned char - unsigned char gives an int), or is this some kind of weird compiler bug (tested with both GCC and clang) ?

Noxbru
  • 372
  • 2
  • 11
  • 3
    This seems [relevant](http://stackoverflow.com/questions/29817927/why-are-integer-types-promoted-during-addition-in-c?rq=1) (promotion is at least similar in C and C++, if not the same). – chris Oct 05 '15 at 23:43
  • 1
    Yeah, any type smaller than `int` promotes to `int` for arithmetic. – ShadowRanger Oct 05 '15 at 23:43
  • Also avoid `reinterpret_cast`, it is implementation-defined. – vsoftco Oct 05 '15 at 23:44

1 Answers1

12

Yes, this is expected, as part of the so-called usual arithmetic conversions combined with the rules for integral promotion.

The exact wording changed between C++03 and C++11, but the end result is the same in this case.


[C++03: 4.5/1]: An rvalue of type char, signed char, unsigned char, short int, or unsigned short int can be converted to an rvalue of type int if int can represent all the values of the source type; otherwise, the source rvalue can be converted to an rvalue of type unsigned int.

[C++03: 4.5/5]: These conversions are called integral promotions.

[C++03: 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:

  • 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 ]


[C++11: 4.5/1]: A prvalue of an integer type other than bool, char16_t, char32_t, or wchar_t whose integer conversion rank (4.13) is less than the rank of int can be converted to a prvalue of type int if int can represent all the values of the source type; otherwise, the source prvalue can be converted to a prvalue of type unsigned int.

[C++11: 4.5/7]: These conversions are called integral promotions.

[C++11: 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:

  • If either operand is of scoped enumeration type (7.2), no conversions are performed; if the other operand does not have the same type, the expression is ill-formed.
  • 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.59 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.
    • 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.
Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
  • 3
    Oooh hang on a minute.. integral promotions for this code in both cases... ooh-er – Lightness Races in Orbit Oct 05 '15 at 23:50
  • @LightnessRacesinOrbit, I was just looking and wondering if that's what happened. Shame, because that was exciting to learn. – chris Oct 05 '15 at 23:51
  • That is really good to know. This is worth a larger, better targeted self-answered question that will be easier to find, Lightness Races in Orbit. Buried here, this answer is likely to be overlooked. – user4581301 Oct 05 '15 at 23:52
  • @LightnessRacesinOrbit Then, because of that rule [C++11: 4.5/1], both uint8_t are being promoted to ints when doing the subtraction. Didn't know that that would happen :/ – Noxbru Oct 06 '15 at 00:01