4 ms·

OTH, the explicitly sized integers (int32_t, int16_t etc) had been added already in C99 (e.g. 25 years ago), and should be used when a specific memory layout of

OTH, the explicitly sized integers (int32_t, int16_t etc) had been added already in C99 (e.g. 25 years ago), and should be used when a specific memory layout of structs is desired.

WalterBright 3y ago
If you're going to use those, then there's no reason to have ints be 64 bit. Personally, I find using int32_t in general to be an uglification of the code. I never use `long` in C code anymore, as it's sometimes 32 bits and sometimes 64 bits. I use `int` and `long long`. Do I care about 16 bit code anymore? No. Very few programs would port between 16/32 these days anyway, no matter what the Standard says or how hard you try to write code portably.
- extraduder_ire 3y ago
  Always thought it was odd how "long long" is one of the only common types that's two words with an implicit int at the end. Almost makes me want to add "typedef long long longer;" to some code that I don't intend anyone to maintain.
- cpeterso 3y ago
  Google’s C++ style guide similarly recommends using ‘int’ in general and never using ‘int32_t’, though it recommends using ‘int64_t’ for bigger numbers instead of ‘long’: https://google.github.io/styleguide/cppguide.html#Integer_Types https://google.github.io/styleguide/cppguide.html#Integer_Ty...
- LeFantome 3y ago
  Is it the numbers you do not like? If you use “long long”, it must not be the length. I don’t love long long. As an amateur compiler writer, it hurts me. “long long” makes “long” both a modifier ( like unsigned is ) and a type. Yuck. I wish it was i8, i16, i32, and i64 ( with u versions of each ). f32 and f64 for floats. Those are easy to understand and fairly easy on the eyes. If those numbers are too noisy, the CIL ( .NET ) types could work. For example, i4 and i8 instead of i32 and i64. I do no love the look of i1 either though. I guess you could special case sbyte and byte as aliases.
  - dzaima 3y ago
    "long" is always a modifier, just potentially applied twice, and potentially to nothing. A more written out version of "long long" is "long long int", and similarly "long" is really "long int".
  - WalterBright 3y ago
    > Is it the numbers you do not like? Correct. > fairly easy on the eyes Not for me. It's a personal thing, I just don't like it. When I removed them all from my code, it was like I'd scraped the barnacles off my boat.
- Gibbon1 3y ago
  I essentially do not use int short, long, long long at all. Frankly I think those were a terrible mistake and people should avoid using them.
  - WalterBright 3y ago
    Anybody who uses "int short" should be keel-hauled. That nonsense did not make its way into D!
    - Gibbon1 3y ago
      The lack of memory safe casts drives me a bit batty. You would think casting something as signed or unsigned wouldn't promote to a int / unsigned int. Ditto for const and unconst.
      - WalterBright 3y ago
        When the first C++ Standard (C89) was being created, about half the compilers implemented "sign preserving" semantics, which is what you're advocating, and the other half implemented "value preserving" semantics. A great battle ensued, and many champions were slain. The value preserving folks carried the field, and the sign preserving folks changed their compilers.

OTH, the explicitly sized integers (int32_t, int16_t etc) had been added already in C99 (e.g. 25 years ago), and should be used when a specific memory layout of structs is desired.

WalterBright 3y ago

If you're going to use those, then there's no reason to have ints be 64 bit. Personally, I find using int32_t in general to be an uglification of the code. I never use `long` in C code anymore, as it's sometimes 32 bits and sometimes 64 bits. I use `int` and `long long`. Do I care about 16 bit code anymore? No. Very few programs would port between 16/32 these days anyway, no matter what the Standard says or how hard you try to write code portably.

extraduder_ire 3y ago
Always thought it was odd how "long long" is one of the only common types that's two words with an implicit int at the end. Almost makes me want to add "typedef long long longer;" to some code that I don't intend anyone to maintain.
cpeterso 3y ago
Google’s C++ style guide similarly recommends using ‘int’ in general and never using ‘int32_t’, though it recommends using ‘int64_t’ for bigger numbers instead of ‘long’: https://google.github.io/styleguide/cppguide.html#Integer_Types https://google.github.io/styleguide/cppguide.html#Integer_Ty...
LeFantome 3y ago
Is it the numbers you do not like? If you use “long long”, it must not be the length. I don’t love long long. As an amateur compiler writer, it hurts me. “long long” makes “long” both a modifier ( like unsigned is ) and a type. Yuck. I wish it was i8, i16, i32, and i64 ( with u versions of each ). f32 and f64 for floats. Those are easy to understand and fairly easy on the eyes. If those numbers are too noisy, the CIL ( .NET ) types could work. For example, i4 and i8 instead of i32 and i64. I do no love the look of i1 either though. I guess you could special case sbyte and byte as aliases.
- dzaima 3y ago
  "long" is always a modifier, just potentially applied twice, and potentially to nothing. A more written out version of "long long" is "long long int", and similarly "long" is really "long int".
- WalterBright 3y ago
  > Is it the numbers you do not like? Correct. > fairly easy on the eyes Not for me. It's a personal thing, I just don't like it. When I removed them all from my code, it was like I'd scraped the barnacles off my boat.
Gibbon1 3y ago
I essentially do not use int short, long, long long at all. Frankly I think those were a terrible mistake and people should avoid using them.
- WalterBright 3y ago
  Anybody who uses "int short" should be keel-hauled. That nonsense did not make its way into D!
  - Gibbon1 3y ago
    The lack of memory safe casts drives me a bit batty. You would think casting something as signed or unsigned wouldn't promote to a int / unsigned int. Ditto for const and unconst.
    - WalterBright 3y ago
      When the first C++ Standard (C89) was being created, about half the compilers implemented "sign preserving" semantics, which is what you're advocating, and the other half implemented "value preserving" semantics. A great battle ensued, and many champions were slain. The value preserving folks carried the field, and the sign preserving folks changed their compilers.