intmax_t is as bad as int, for precisely the same reason. The developer has no idea what the capabilities of the type are. "Give me the biggest integer type you have" is not something any developer should say, ever, at least not in code that is intended to be remotely portable across time, space and architecture.

I would put "char" in the running now that we (thankfully) live in an increasingly UTF-8 world, but at least it's more or less universally understood to mean an 8 bit entity (even though this is not strictly true). It certainly isn't "a character".

    std::is_signed<decltype(1L * 2U)>()

?

If sizeof(long) == sizeof(unsigned int), 1L * 2U results in an unsigned int, meaning the result is "false".

If sizeof(long) > sizeof(unsigned int), 1L * 2U result in a signed long, meaning the result is "true".

  max(
    static_cast<intmax_t>(
      numeric_limits<T>::lowest()),
    static_cast<intmax_t>(
      numeric_limits<U>::lowest()))

    numeric_limits<T>::min()

    numeric_limits<T>::lowest()

intmax_t exists probably because most integer types in C are not portable. You can't write C code that uses int64_t and expect it to compile, the type doesn't have to exist, neither do int32_t or int16_t. Say you have a generic int lowestBitSet(intmax_t) function and want to make it available, you don't care how large the input integer is as long as you do not truncate the largest type available to whoever ends up using it. Without intmax_t you end up with library developers having to either setting their own upper limit, limiting the portability of their library or checking for the availability of each type themselves.

intmax_t doesn't define an upper limit either, as TFA explains, because you don't know at runtime what the limit really is.

The idea for the library writer are that the bounds are large enough for whatever the user needs. User inputs a int64_t? Great the type intmax_t on that system is at least int64_t wide by definition. System doesn't have a int64_t ? Great the user can at best use a int32_t, which intmax_t would once again support.

> intmax_t doesn't define an upper limit either, as TFA explains

Yeah, it would almost be sad that C++ is getting bitten by Cs lack of name mangling. Almost because it is kinda pointless to define a maximum integer in a language where any programmer can add their own fixed sized integer types, so a generic library supporting arbitrary sized integers would have to take template parameters anyway.

And C99 requires long longs to be at least 64 bits wide.

I agree that intmax is silly, but I believe there are legitimate uses for variable-size types, like int_fast8_t and uint_fast16_t. These are their nominal size on x86 because the architecture has arithmetic operations for those sizes. But on POWER, they are both 32-bit types, because there are no 8-bit or 16-bit opcodes, and emulating overflow behavior with bitmasks incurs a performance hit.

The number of cases where it’s important to use different types on different architectures exists, but is very small.

That’s something that would be much easier to handle at the library-level for a finite set of architectures than at the language level for all archs.

I’d also like to see the elimination of printf specifiers. Another total disaster and source of soooooo many bugs. Especially with all of these variable types.

Heck, I use 64-bit ints on 8051 cores that make an AVR look like something out of Star Trek.

https://stackoverflow.com/questions/8500677/what-is-uint-fas...