5 ms·

It seems the original sin was having an intmax type in the first place, instead of only fixed-size types. And then of course the stupidity in using it: just bec

It seems the original sin was having an intmax type in the first place, instead of only fixed-size types. And then of course the stupidity in using it: just because a high-end CPU can do math on 512 bit integers within some 10-20 cycles shouldn't mean that after a recompile all the chrono code is suddenly a huge register stomping inefficient mess, for no good fucking reason at all. And on the other end of the spectrum, someone might well decide 16 bit is the intmax for an AVR8. Now your chrono code doesn't work at all.

saagarjha 6y ago
But if you used a fixed size type, you end up doing things like using 64-bit integers on AVR, where you’re going to again have a bad time. Flexible and fixed width types both have their uses.
PaulDavisThe1st 6y ago
This, this and more this. 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.
- SloopJon 6y ago
  I used intmax_t just yesterday in an ODBC type conversion test. I wrote a template for use in a Google Test typed test to find the highest and lowest values supported by the client and server type. Something like: max( static_cast<intmax_t>( numeric_limits<T>::lowest()), static_cast<intmax_t>( numeric_limits<U>::lowest())) I tried std::common_type first, but it didn't quite do the trick.
  - secondcoming 6y ago
    Out of curiosity... did you ever fall into the trap of using numeric_limits<T>::min() instead of numeric_limits<T>::lowest() ? Because I did.
    - saagarjha 6y ago
      The distinction is only relevant for floating point types, is it not?
      - secondcoming 6y ago
        Yes, I believe so.
    - SloopJon 6y ago
      Yeah, min() returns the most negative int, so it seems like it should do the same for float. Then the float with the least magnitude could have been, say, smallest().
- TwoBit 6y ago
  The only type worse than 'int' is 'long'.
  - PaulDavisThe1st 6y ago
    it's really a tie between "int", "long" and DWORD (though thankfully DWORD never made it into a language standard). 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".
    - mehrdadn 6y ago
      long is definitely worse than int. At least you know int is never 64-bit on desktops, and it comes in handy enough for things like logarithms. long being either 32-bit or 64-bit on the same platform depending on the compiler just feels like insanity.
      - MaulingMonkey 6y ago
        It's absolutely insanity. A cruel question I came up with the other day, based on it - What is the result of: std::is_signed<decltype(1L * 2U)>() ?
        folmar 6y ago
        Why should it be cruel? Promotions are a part of life of an integer in C.
        MaulingMonkey 6y ago
        Even programmers who are roughly aware of integral promotion rules may not have connected all the dots to realize the answer is implementation dependent. 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".
- josefx 6y ago
  > at least not in code that is intended to be remotely portable across time, space and architecture. 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.
  - PaulDavisThe1st 6y ago
    I don't use int64_t and expect it to exist. I use int64_t and expect compilation to fail if stdint.h doesn't define it. It would be a problem, but much less of a problem than using intWhatever_t, having compilation work, but having no idea what the bounds were. intmax_t doesn't define an upper limit either, as TFA explains, because you don't know at runtime what the limit really is.
    - josefx 6y ago
      > but having no idea what the bounds were. 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.
  - young_unixer 6y ago
    The standard requires longs to be at least 32 bits wide. Then how can int32_t not exist? And C99 requires long longs to be at least 64 bits wide.
kps 6y ago
C99, which introduced `intmax_t`, also requires that a compiler provide a `long long int` of at least 64 bits. So on the bright side, `intmax_t` will be at least 64 bits, and on the down side, you really don't want to use that type on an AVR.
- loeg 6y ago
  It's probably fine for addition on an AVR, but I'm having trouble imagining what you'd want to count that needs more than 32 bits on an AVR.
  - CamperBob2 6y ago
    Tick counts. It's nice to be able to do time-difference subtractions (and comparisons!) without worrying about rollover. Heck, I use 64-bit ints on 8051 cores that make an AVR look like something out of Star Trek.
oofabz 6y ago
>only fixed-size types 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.
- forrestthewoods 6y ago
  Implementing this has the language level has proven to be a total disaster. 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.
secondcoming 6y ago
Indeed. And look at all the uint_fast32_t, etc, stuff too: https://stackoverflow.com/questions/8500677/what-is-uint-fast32-t-and-why-should-it-be-used-instead-of-the-regular-int-and-u https://stackoverflow.com/questions/8500677/what-is-uint-fas...
forrestthewoods 6y ago
Agreed 100%

saagarjha 6y ago

But if you used a fixed size type, you end up doing things like using 64-bit integers on AVR, where you’re going to again have a bad time. Flexible and fixed width types both have their uses.

PaulDavisThe1st 6y ago

This, this and more this. 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.

SloopJon 6y ago
I used intmax_t just yesterday in an ODBC type conversion test. I wrote a template for use in a Google Test typed test to find the highest and lowest values supported by the client and server type. Something like: max( static_cast<intmax_t>( numeric_limits<T>::lowest()), static_cast<intmax_t>( numeric_limits<U>::lowest())) I tried std::common_type first, but it didn't quite do the trick.
- secondcoming 6y ago
  Out of curiosity... did you ever fall into the trap of using numeric_limits<T>::min() instead of numeric_limits<T>::lowest() ? Because I did.
  - saagarjha 6y ago
    The distinction is only relevant for floating point types, is it not?
    - secondcoming 6y ago
      Yes, I believe so.
  - SloopJon 6y ago
    Yeah, min() returns the most negative int, so it seems like it should do the same for float. Then the float with the least magnitude could have been, say, smallest().
TwoBit 6y ago
The only type worse than 'int' is 'long'.
- PaulDavisThe1st 6y ago
  it's really a tie between "int", "long" and DWORD (though thankfully DWORD never made it into a language standard). 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".
  - mehrdadn 6y ago
    long is definitely worse than int. At least you know int is never 64-bit on desktops, and it comes in handy enough for things like logarithms. long being either 32-bit or 64-bit on the same platform depending on the compiler just feels like insanity.
    - MaulingMonkey 6y ago
      It's absolutely insanity. A cruel question I came up with the other day, based on it - What is the result of: std::is_signed<decltype(1L * 2U)>() ?
      - folmar 6y ago
        Why should it be cruel? Promotions are a part of life of an integer in C.
        MaulingMonkey 6y ago
        Even programmers who are roughly aware of integral promotion rules may not have connected all the dots to realize the answer is implementation dependent. 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".
josefx 6y ago
> at least not in code that is intended to be remotely portable across time, space and architecture. 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.
- PaulDavisThe1st 6y ago
  I don't use int64_t and expect it to exist. I use int64_t and expect compilation to fail if stdint.h doesn't define it. It would be a problem, but much less of a problem than using intWhatever_t, having compilation work, but having no idea what the bounds were. intmax_t doesn't define an upper limit either, as TFA explains, because you don't know at runtime what the limit really is.
  - josefx 6y ago
    > but having no idea what the bounds were. 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.
- young_unixer 6y ago
  The standard requires longs to be at least 32 bits wide. Then how can int32_t not exist? And C99 requires long longs to be at least 64 bits wide.

kps 6y ago

C99, which introduced `intmax_t`, also requires that a compiler provide a `long long int` of at least 64 bits. So on the bright side, `intmax_t` will be at least 64 bits, and on the down side, you really don't want to use that type on an AVR.

loeg 6y ago
It's probably fine for addition on an AVR, but I'm having trouble imagining what you'd want to count that needs more than 32 bits on an AVR.
- CamperBob2 6y ago
  Tick counts. It's nice to be able to do time-difference subtractions (and comparisons!) without worrying about rollover. Heck, I use 64-bit ints on 8051 cores that make an AVR look like something out of Star Trek.

oofabz 6y ago

>only fixed-size types 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.

forrestthewoods 6y ago
Implementing this has the language level has proven to be a total disaster. 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.

secondcoming 6y ago

Indeed. And look at all the uint_fast32_t, etc, stuff too: https://stackoverflow.com/questions/8500677/what-is-uint-fast32-t-and-why-should-it-be-used-instead-of-the-regular-int-and-u https://stackoverflow.com/questions/8500677/what-is-uint-fas...

forrestthewoods 6y ago

Agreed 100%