4 ms·
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
by 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 agoC++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 agoOn 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 agoMany 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 agoThat 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 agoI 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.