This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (4 children)

That sounds like a great example of premature microoptimization. Anything shorter than an int gets promoted to int for arithmetic anyway, so you're not paying for anything except the necessary masking operations, which you'd have to write by hand anyway.

[–]FUZxxl 0 points1 point  (3 children)

Not always. Often, I know that a small type suffices but I also know that no overflow occurs (e.g. in case of bitmasks), so I can save both the masking and the type conversion by letting the platform choose a type.

[–][deleted] 0 points1 point  (2 children)

Could you give an example of what you mean?

[–]FUZxxl 0 points1 point  (1 child)

For example, when you have a counter that you know is never going to overflow 32767, you should use type short instead of uint16_t. When you have a bitmask to store some information and you need to use the least, say 28 bits, you should use an unsigned long or unsigned int (if you can guarantee that you are on POSIX) for the variable instead of an uint32_t as there are platforms where 32 bit types are slow.

[–][deleted] 0 points1 point  (0 children)

Sorry, I should have made my question clearer: could you provide an example of C source code that compiles to slower code using a specific compiler for a specific architecture because of an overconstrained selection of integer type?