When should one use the datatypes from stdint.h?
Is it right to always use as a convention them?
What was the purpose of the design of nonspecific size types like int and short?
uint32_t vs int – Everyday Programming Conventions
c++intuint32
Related Solutions
Between int32 and int32_t, (and likewise between int8 and int8_t) the difference is pretty simple: the C standard defines int8_t and int32_t, but does not define anything named int8 or int32 -- the latter (if they exist at all) is probably from some other header or library (most likely predates the addition of int8_t and int32_t in C99).
Plain int is quite a bit different from the others. Where int8_t and int32_t each have a specified size, int can be any size >= 16 bits. At different times, both 16 bits and 32 bits have been reasonably common (and for a 64-bit implementation, it should probably be 64 bits).
On the other hand, int is guaranteed to be present in every implementation of C, where int8_t and int32_t are not. It's probably open to question whether this matters to you though. If you use C on small embedded systems and/or older compilers, it may be a problem. If you use it primarily with a modern compiler on desktop/server machines, it probably won't be.
Oops -- missed the part about char. You'd use int8_t instead of char if (and only if) you want an integer type guaranteed to be exactly 8 bits in size. If you want to store characters, you probably want to use char instead. Its size can vary (in terms of number of bits) but it's guaranteed to be exactly one byte. One slight oddity though: there's no guarantee about whether a plain char is signed or unsigned (and many compilers can make it either one, depending on a compile-time flag). If you need to ensure its being either signed or unsigned, you need to specify that explicitly.
what's the difference with uint32_t
uint_fast32_t is an unsigned type of at least 32 bits that is (in some general way) the fastest such type. "fast" means that given a choice, the implementer will probably pick the size for which the architecture has arithmetic, load and store instructions. It's not the winner of any particular benchmark.
uint_least32_t is the smallest unsigned type of at least 32 bits.
uint32_t is a type of exactly 32 bits with no padding, if any such type exists.
Am I right?
No. If uint24_t exists at all then it is an integer type, not a struct. If there is no unsigned integer type of 24 bits in this implementation then it does not exist.
Since unsigned long is required to be at least 32 bits, the only standard types that uint24_t could possibly ever be an alias for are char, unsigned char, unsigned short and unsigned int. Alternatively it could be an extended type (that is, an integer type provided by the implementation that is not any of the defined integer types in the standard).
Will you suggest me to use uint48_t for my 48-bit unsigned integers?
If it exists and is the size you want then you might as well use it. However, it will not exist on very many implementations, so it's only suitable for use in non-portable code. That's OK provided the reason you have to deal with exact 48-bit integers is platform-specific.
The exact 16, 32 and 64 bit types are also technically optional, but they are required to exist if the implementation has suitable integer types. "Suitable" means not only that there is an exact N bit unsigned type with no padding bits, but also that the corresponding signed type has no padding bits and uses 2's complement representation. In practice this is so close to everywhere that you limit portability very little by using any of them. For maximum portability though you should use uint_least32_t or uint_fast32_t in preference to uint32_t. Which one depends on whether you care more about speed or size. In my experience very few people bother, since platforms that don't have a 32 bit integer type are already so weird that most people don't care whether their code runs on it or not.
Best Answer
Things are leaning that way. The fixed width types are a more recent addition to C. Original C had
char, short, int, longand that was progressive as it tried, without being too specific, to accommodate the various integer sizes available across a wide variety of processors and environments. As C is 40ish years old, it speaks to the success of that strategy. Much C code has been written and successfully copes with the soft integer specification size. With increasing needs for consistency,char, short, int, long and long long, are not enough (or at least not so easy) and soint8_t, int16_t, int32_t, int64_tare born. New languages tend to require very specific fixed integer size types and 2's complement. As they are successfully, that Darwinian pressure will push on C. My crystal ball says we will see a slow migration to increasing uses of fixed width types in C.It was a good first step to accommodate the wide variety of various integer widths (8,9,12,18,36, etc.) and encodings (2's, 1's, sign/mag). So much coding today uses power-of-2 size integers with 2's complement, that one may not realize that many other arrangements existed beforehand. See this answer also.