jahboater wrote: ↑
Thu Oct 03, 2019 11:42 am
sal55 wrote: ↑
Thu Oct 03, 2019 11:29 am
Whereas more modern languages that have ranges of fixed-width types have standardized on widths of 8, 16, 32 and 64 bits, including Rust.
Precisely what C did 20 years ago ...
C99 introduced exact width types and others such as int_fast and int_least.
They may have introduced them, but nobody uses them! At least, they seem to be rare in open-source code I've looked at.
Forget about what they may map onto, it is of no interest to the programmer.
(sure int64_t may be slow on a 32-bit platform, but it works perfectly. There is no need for the code to be aware.)
This is it, they may map to the poorly defined char, short, int, long, long long (notice FIVE types which normally represent FOUR sizes of 8, 16, 32, 64).
'uint64_t' might map to 'unsigned long long int' on Windows, or 'unsigned long int' on Linux. This is important if you want to know whether to use "%lu" or "%llu" when printing its value (or you have to use PRi64d or whatever). It is little help when trying to call 'sprintf' as a foreign function from another language.
It's also important when your code, for example, might use int64_t*, but you want to call a library function that needs 'long int*' or 'long long int*. It's still a mess!
CHAR_BIT is fixed at 8 (when did you last see a computer with 6 or 9 bit bytes?)
CHAR_BIT is at least
8 bits; POSIX implementations mandate 8 bits. But there are still special processors that don't have an 8-bit byte, so it either needs emulating, or CHAR_BIT for that device will be 16 or 24 or 32 or 37.
Yes the older types such as long may change between 32 and 64 bit platforms, which is sometimes useful.
When is that? I've just glanced at the ScriptBasic sources (it was mentioned a few posts above) and they seem to use 'long' extensively. Which means that when long is 64 bits, and the hardware is 32 bits, it will now be wasting time doing unnecessary 64-bit ops. (And if it expects long to be 64 bits, it will fail when it's only 32.)