The "abstract machine" as defined by the standard only defines built-in integer operations (arithmetic and comparison) for the types int, long and long long. In most cases this means arithmetic is only defined for 2 sizes of integer. There is no arithmetic operation that can be done directly on types smaller than int, like a short or signed char. Since std::uint_16 is typically a typedef to unsigned short on machines where short is 16 bits wide, then arithmetic cannot be performed directly on uint_16.

Most likely, there could exist machines which support arithmetic only for its natural word size (which is int), while also supporting reading/writing smaller size integer to memory. In hardware terms, this could mean the ALU only supports int as operands. I think that recent RISC architectures tend to implement only 2 sizes for integer built-in operations (int and long).

Since arithmetic on small integer is not possible, then those small integers must undergo a conversion to widen the integer so that it can be input to the ALU.

There's one point that is very nasty about promotions IMHO: it is when the promotion changes the signedness of the operand. This is especially bad because it will change the semantics of comparisons. This signedness change behavior is also fragile when compiling to different architectures: a signed char or a short could promote to either signed int or unsigned int depending on the target machine. It would be better if promotions could never change signedness.

Julien V.

On March 29, 2025 3:02:22 p.m. EDT, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>It's horrible when you use a "std::uint16_t" only to find that it
>promotes to a signed 32-Bit integer. Believe it or not, I recently
>wrote the following code:
>
> using std::uint_fast32_t;
> // We can't use uint_fast32_t if it undergoes promotion,
> // so instead use long unsigned (which might be 64-Bit)
> typedef typename std::conditional<
> std::is_same< uint_fast32_t, decltype(uint_fast32_t() +
>uint_fast32_t()) >::value,
> uint_fast32_t,
> long unsigned >::type UIntType;
>
>So how about if we could tell the compiler that we want to use a
>specific integer type, and that we don't want it to promote. Perhaps
>here's how we'd define such an integer:
>
> short unsigned _NoPromo n = 0xFFFF;
>
>And similarly, if we already have a variable, and we want to do some
>calculations without it promoting at some point, then we make a
>_NoPromo reference to it:
>
> short unsigned original_variable = 0xFFFF;
>
> short unsigned _NoPromo &safe_variable = original_variable;
>
> safe_variable = ~safe_variable; // no promotion takes place here
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals