3 ms·

I find it weird that the convention to use char/short/int/long/long long has persisted so widely to this day. I would have thought that already back in the 16 -

• chipdart 2y ago
  > I find it weird that the convention to use char/short/int/long/long long has persisted so widely to this day. I don't think this is a reasonable take. Beyond ABI requirements and how developers use int over short, there are indeed requirements where the size of an integer value matters a lot, specially as this has a direct impact on data size and vectorization. To frame your analysis, I would recommend you took a peek at the not-so-recent push for hardware support for IEEE754 half-precision float/float16 types.
  • zokier 2y ago
    The cases where you want platform-specific integer width (that is not something like size_t/uintptr_t) is extremely niche compared to cases where you want integer to have specific width. I don't see the relation to fp16; I don't think anyone is pushing for `float` to refer to fp16 (or fp64 for that matter) anywhere. `long double` is already bad enough.
    • manwe150 2y ago
      My recollection of history is that the standardization of stdint.h happened long after the transition to 32 bit, and is only just finishing up becoming available on some major compilers after the transition to 64 bit is well behind us
      • jcranmer 2y ago
        stdint.h was introduced in C99, and MSVC didn't introduce it until 2010.
      • layer8 2y ago
        You could fairly easily create your own portable stdint.h equivalent in C89 (using the preprocessor and INT_MAX etc.). I remember doing that in the 90s, before C99. However, it was also conventional wisdom to use int by default to match the architecture’s “natural” word size, and maybe add a preprocessor check when you needed it to be 32-bit. Another consideration is that the built-in types have to be used with the C standard library functions to some extent.
    • chipdart 2y ago
      > The cases where you want platform-specific integer width (that is not something like size_t/uintptr_t) is extremely niche (...) I think you got it backwards. There are platform-specific ints because different processors have different word sizes. Programing languages then adjust their definitions for these word sizes because they are handled naturally by specific processors. So differences in word sizes exist between processors. Either programming languages support them, or they don't. Also, there is also specific needs to handle specific int sizes regardless of cpu architecture. Either programming languages support them, or don't. And you end with "platform-specific integer widths" because programming languages do the right thing and support them.
      • zokier 2y ago
        The fact that we have all these different 64 bit data models demonstrates clearly how the connection between word size and C types is completely arbitrary and largely meaningless. And this is not specific to 64 bit either, same sort of thing happens on 8 bit platforms too. So you can not rely on `int` (or any other type) being word sized. Furthermore I argue that word size is not really something that makes sense to even expose at language level, the whole concept of word size is somewhat questionable. CPUs operate on all sort of things that can have different sizes, trying to reduce that to single "word size" is futile.
• jraph 2y ago
  I see two good reasons: (1) DX: typing "int" feels more natural and less clunky than choosing some arbitrary size. (2) Perf: if you don't care about the size, you might as well use the native size, which is supposed to be faster. In Java, people do use the hardware-independent 4 byte ints and 8 byte longs. I guess (1) matters more, or that people think that the JVM will figure out the perf issue and that it'll be possible to micro-optimize if a profile pointed out an issue.
  • epcoa 2y ago
    > Perf: if you don't care about the size, you might as well use the native size, which is supposed to be faster. You always care about the size (or should), especially if you're writing C or C++. Though it is often reasonable that 32767 is a sufficient limit and you're guaranteed at least that with int.
    • jraph 2y ago
      What I meant is that if you don't specifically need a small int size (because for instance you are going to serialize it into a format that mandates it), and you will not deal with even moderately large ints, you will probably use int even if you could use a smaller type. I've not seen many codebases doing something else. Of course you need to think about it. In C, but also in many languages (not python though, which magically switch to bigint when needed). In Java, the wrong int type won't cause UB, but it will throw (unchecked) exceptions.
  • Tuna-Fish 2y ago
    > which is supposed to be faster. If you care about this, you figure out exactly how much you need and always use the smallest type that meets this criteria. There have been architectures in the past where the "native" size was in practice faster than the smaller types, but those architectures are now long dead. On all modern architectures, none of the instructions for smaller data types are ever slower than the native size, and while using them doesn't directly win you cycles of execution time in the cpu (because they are no faster either), it wins you better cache utilization. As a rule, the fastest data type is a byte. There is no reason to ever use "int", other than inertia.
• loeg 2y ago
  The stdint types only date to C99. 32-bit transition happened much earlier than that.