Question

So the reason for typedef:ed primitive data types is to abstract the low-level representation and make it easier to comprehend (uint64_t instead of long long type, which is 8 bytes).

However, there is uint_fast32_t which has the same typedef as uint32_t. Will using the “fast” version make the program faster?

Answer 1

• int may be as small as 16 bits on some platforms. It may not be sufficient for your application.
• uint32_t is not guaranteed to exist. It’s an optional typedef that the implementation must provide iff it has an unsigned integer type of exactly 32-bits. Some have a 9-bit bytes for example, so they don’t have a uint32_t.
• uint_fast32_t states your intent clearly: it’s a type of at least 32 bits which is the best from a performance point-of-view. uint_fast32_t may be in fact 64 bits long. It’s up to the implementation.
• There’s also uint_least32_t in the mix. It designates the smallest type that’s at least 32 bits long, thus it can be smaller than uint_fast32_t. It’s an alternative to uint32_t if the later isn’t supported by the platform.

… there is uint_fast32_t which has the same typedef as uint32_t …

What you are looking at is not the standard. It’s a particular implementation (BlackBerry). So you can’t deduce from there that uint_fast32_t is always the same as uint32_t.

See also:

• Exotic architectures the standards committees care about.

• My pragmatic opinion about integer types in C and C++.