OSDev.org

bluemoon wrote:1. num must be the type of uint8_t, or you'll get conversion warning
2. the compiler may generate 8-bit instruction(if available in architecture), but this wouldn't save instruction count. Also, 8 bit instruction would not run faster than 32-bit instruction.
3. the compiler push full 32-bit on stack anyway
4. it get worst when the type is uint16_t

This is obviously a stupid example functiom, but 2. Is wrong. There are cases where the 8-bit verison of an instruction runs faster than the 32-bit version, on x86. DIV is the prime example; it takes time linear in the number of bits.

The question to ask is "What is bounding the size of this?"

• Memory? Use size_t
• Some piece of hardware? Use a fixed width type of appropriate size (and if you're porting to platforms with non-8-bit-multiple-bytes, minumum or fastest size types: uint16_least_t or uint16_fast_t)
• Nothing in particular? Then consider the fundamental types, if they offer sufficient range, but also now take care when passing input to them from other sources.

Now, one of the most common, annoying and stupid things I see people do while programming in C and C++ is using signed types when what they really should be using are unsigned types.

That is just silly.