5 ms·

I've never really liked the short/int/long definitions. They're just out there to confuse you, especially if you've written your share of assembly. For as long

by yason 11y ago

I've never really liked the short/int/long definitions. They're just out there to confuse you, especially if you've written your share of assembly. For as long as I can remember I've just used size_t, uintptr_t, uint32_t/int32_t (or any of the 16/32/64 variants), exactly because I want to be explicit about the machine word sizes I'll be dealing with. Before that, I always used similar (u32/i32, LONG/ULONG, ...) platform-specific typedefs on proprietary systems too. For all practical purposes, int/unsigned int has been at least 32 bits since the early 90's (well, on modern platforms) but why use those if you can explicitly declare how many bits you actually need. (I've bumped into a few archaic platforms where stdint headers weren't present but it's easy to just add a few build-specific typedefs somewhere in that case.)

antimagic 11y ago
Well I know historically it was because there were potentially performance issues with using explicit sizes - int was basically the guarantee that you would be working in the CPU's native size, and hence at it's most efficient, no need to shift and mask bits to get the value that you wanted. Obviously this leads straight to a bunch of relatively subtle bugs, but I guess for some applications the tradeoff of speed vs safety was worth it.
- ordinary 11y ago
  C++11 has improved the situation somewhat by making it possible to explicit state what you want from your numeric types: http://en.cppreference.com/w/cpp/types/integer http://en.cppreference.com/w/cpp/types/integer
  - mbel 11y ago
    <stdint.h> was actually introduced by C99 and included in C++11 with other C99 changes.
- Gibbon1 11y ago
  On 8 bit machines it's the reverse, an int being 16 bits minimum requires more operations to handle than an 8 bit number. Pass an 'int' push two things on the stack. Etc. Causes your code size to balloon noticeably.
  - revelation 11y ago
    Many 8bit processors such as AVR have instructions that work with 16 bit numbers (stored in register pairs). So that's not the case.
    - kevin_thibedeau 11y ago
      That only applies to adds, subtracts, and register moves. 16-bit Booleans, shifts/rotates, multiplies, and load/store still need to be done with multiple instructions.
      - Gibbon1 11y ago
        I did a little mucking on some AVR code of mine. Sometimes going from an uint8_t to a uint16_t saves a couple of bytes Sometimes adds a dozen. One case changing an index in a for loop to an int, code went from 34024 bytes to 34018 (saved four bytes). But changing uint8_t i, j, k; to uint16_t i, j, k; code compiled to 34068 bytes, gain of 44 bytes.
halflings 11y ago
Maybe it's there for those that don't care about that sort of "details". If all you care about is passing around some small numbers, int does the job :)!
ars 11y ago
The biggest frustration with those types is printf: "Num: %" PRIuFAST32 " found\n" Is quite annoying to type instead of: "Num: %d found\n"
- coldpie 11y ago
  I always found it odd that there's no printf extension to just automatically print the correct integer size. GCC is already smart enough to tell me if %d is wrong for a long; why can't I just do %N and have it print out the correct length for the argument?
  - yoklov 11y ago
    Because printf is just a function, and doesn't have access to the type information at the call-site.
    - delan 11y ago
      Just a hypothetical idea: what if the standard allowed a compiler to modify the format string during compilation, replacing e.g. %N with the appropriate conversion specification, subject to proving that a given format string is a plain old literal that is not touched anywhere else?
      - coldpie 11y ago
        This is exactly what I was suggesting. The compiler definitely has that information.
        seiji 11y ago
        It's a good idea, but then you are tied to one compiler. So, what if Clang implements it, but not GCC? Or what if Clang and GCC implement it, but not the Sun or Intel compilers? Or what about all the GCC copies every board maker forks when they create something custom? It's tricky making in-compiler behavior non-standard (though, I guess that's what compiler flags are for).
seiji 11y ago
Let's also mention how utterly moronic it is to type three our four entire english words for one type definition. Do you really want to type `unsigned long long int x = 4` all the time? No, you should never type that. It should always be `uint64_t x = 4`. (That's also ignoring the mental indirection required for every line of code that experienced programmers take for granted. Try explaining to a new programmer why 'long' changes storage size on platforms or why 'long long' and 'long' is usually, but not always the same size. Be explicit, not english.) Basically, if you are still typing "unsigned long long" or even "long" in 2015 in a modern environment, please stop. But—you may say—we want long to be 32 bit on 32 bits and 64 bit on 64 bits! No, you don't. That makes your system difficult to reason about. Plus, you'll probably start casting your inputs to printf() instead of using proper printf type macros, which breaks things even further. Adopt proper types, use proper types, stop programming like it's 1975. Good luck.

by yason 11y ago

antimagic 11y ago

Well I know historically it was because there were potentially performance issues with using explicit sizes - int was basically the guarantee that you would be working in the CPU's native size, and hence at it's most efficient, no need to shift and mask bits to get the value that you wanted. Obviously this leads straight to a bunch of relatively subtle bugs, but I guess for some applications the tradeoff of speed vs safety was worth it.

ordinary 11y ago
C++11 has improved the situation somewhat by making it possible to explicit state what you want from your numeric types: http://en.cppreference.com/w/cpp/types/integer http://en.cppreference.com/w/cpp/types/integer
- mbel 11y ago
  <stdint.h> was actually introduced by C99 and included in C++11 with other C99 changes.
Gibbon1 11y ago
On 8 bit machines it's the reverse, an int being 16 bits minimum requires more operations to handle than an 8 bit number. Pass an 'int' push two things on the stack. Etc. Causes your code size to balloon noticeably.
- revelation 11y ago
  Many 8bit processors such as AVR have instructions that work with 16 bit numbers (stored in register pairs). So that's not the case.
  - kevin_thibedeau 11y ago
    That only applies to adds, subtracts, and register moves. 16-bit Booleans, shifts/rotates, multiplies, and load/store still need to be done with multiple instructions.
    - Gibbon1 11y ago
      I did a little mucking on some AVR code of mine. Sometimes going from an uint8_t to a uint16_t saves a couple of bytes Sometimes adds a dozen. One case changing an index in a for loop to an int, code went from 34024 bytes to 34018 (saved four bytes). But changing uint8_t i, j, k; to uint16_t i, j, k; code compiled to 34068 bytes, gain of 44 bytes.

halflings 11y ago

Maybe it's there for those that don't care about that sort of "details". If all you care about is passing around some small numbers, int does the job :)!

ars 11y ago

The biggest frustration with those types is printf: "Num: %" PRIuFAST32 " found\n" Is quite annoying to type instead of: "Num: %d found\n"

coldpie 11y ago
I always found it odd that there's no printf extension to just automatically print the correct integer size. GCC is already smart enough to tell me if %d is wrong for a long; why can't I just do %N and have it print out the correct length for the argument?
- yoklov 11y ago
  Because printf is just a function, and doesn't have access to the type information at the call-site.
  - delan 11y ago
    Just a hypothetical idea: what if the standard allowed a compiler to modify the format string during compilation, replacing e.g. %N with the appropriate conversion specification, subject to proving that a given format string is a plain old literal that is not touched anywhere else?
    - coldpie 11y ago
      This is exactly what I was suggesting. The compiler definitely has that information.
      - seiji 11y ago
        It's a good idea, but then you are tied to one compiler. So, what if Clang implements it, but not GCC? Or what if Clang and GCC implement it, but not the Sun or Intel compilers? Or what about all the GCC copies every board maker forks when they create something custom? It's tricky making in-compiler behavior non-standard (though, I guess that's what compiler flags are for).

seiji 11y ago

Let's also mention how utterly moronic it is to type three our four entire english words for one type definition. Do you really want to type `unsigned long long int x = 4` all the time? No, you should never type that. It should always be `uint64_t x = 4`. (That's also ignoring the mental indirection required for every line of code that experienced programmers take for granted. Try explaining to a new programmer why 'long' changes storage size on platforms or why 'long long' and 'long' is usually, but not always the same size. Be explicit, not english.) Basically, if you are still typing "unsigned long long" or even "long" in 2015 in a modern environment, please stop. But—you may say—we want long to be 32 bit on 32 bits and 64 bit on 64 bits! No, you don't. That makes your system difficult to reason about. Plus, you'll probably start casting your inputs to printf() instead of using proper printf type macros, which breaks things even further. Adopt proper types, use proper types, stop programming like it's 1975. Good luck.