5 ms·
Don't agree with that either. IMHO, "int" is perfectly acceptable if you just want to use the platform's preferred word size (and are fine with the possibility
by CrLf 11y ago
Don't agree with that either.
IMHO, "int" is perfectly acceptable if you just want to use the platform's preferred word size (and are fine with the possibility of it being only 16bit). Also, "char" is perfectly acceptable too if you're dealing with ASCII. This is valid for both the signed and unsigned variants.
The general rule should be using the language types as long as you're not assuming something about their size, only then use "stdint.h" because it makes your assumption more explicit.
Now, nobody uses "short" or "long" to mean "something smaller or shorter than the platform's int", so these are usually something to avoid.
- xcgvgh 11y agoI use long when I need an int that can always represent ranges in -2^31-1 to 2^31-1, no assumptions necessary. Same goes for unsigned versions and long long.
- lmm 11y agoSo int32_t, but making overflow bugs intermittent and architecture-dependent? Why would you want that?
- AndyKelley 11y agoIs "the platform's preferred word size" meaningful? On x86_64, pointers are 8 bytes, but it's still faster to use smaller registers if you don't need the extra bits. For this system, at least, the correct type is the smallest one that is big enough to hold the maximum value your integer could be.
- mpu 11y agoBullshit, on x64 all 32 or 64 bit base arithmetic operations have the exact same cost, except the 64 bit version is one byte longer because of a REX prefix. This is why 32 bits is the natural int size for x64.
- amadvance 11y agoBeing smaller usually results also in being faster for the cache effect.
- vardump 11y agoWell, at least division isn't. On reasonable recent Intel Broadwell, signed 64-bit division (IDIV) takes 59 cycles, while signed 32-bit division takes just 9 cycles. Granted, divisions are rare, but that's still nearly an order of magnitude difference in that corner case. 32-bit and 64-bit addition, multiplication, comparison, logical operations etc. are in almost all cases just as fast. You'll still need more storage on the stack for 64-bit variables. So more cache misses (and perhaps TLB misses and page faults) when corresponding boundary is crossed.