Motivation for using size_t uint32 uint64 etc

Question

When I reading some code, for integer, they use bunch of different type such as size_t, uint32, uint64 etc. What is the motivation or purpose to do this? Why not ju

Answer 1

These are for platform-independence.

size_t is, by definition, the type returned by sizeof. It is large enough to represent the largest object on the target system.

Not so many years ago, 32 bits would have been enough for any platform. 64 bits is enough today. But who knows how many bits will be needed 5, 10, or 50 years from now?

By writing your code not to care -- i.e., always use size_t when you mean "size of an object" -- you can write code that will actually compile and run 5, 10, or 50 years from now. Or at least have a fighting chance.

Use the types to say what you mean. If for some reason you require a specific number of bits (probably only when dealing with an externally-defined format), use a size-specific type. If you want something that is "the natural word size of the machine" -- i.e., fast -- use int.

If you are dealing with a programmatic interface like sizeof or strlen, use the data type appropriate for that interface, like size_t.

And never try to assign one type to another unless it is large enough to hold the value by definition.

Answer 2

For info on size_t, see the Stack Overflow question: What is size_t in C?

You're right for uint32 and uint64 that they're just being specific about the number of bits that they would like, and that the compiler should interpret them as unsigned.

Answer 3

There are many possible reasons for choosing an underlying type for an integer value. The most obvious one is the size of the maximum possible value that you can store -- uint32 will be able to store a number twice as large as int32, which might be desirable. int64 will be able to store a number much larger than int32 - up to 2^63 - 1 instead of 2^31 - 1.

There are other possible reasons as well. If you're directly reading binary data from some source (file, socket, etc), it is necessary to make sure it's interpreted correctly. If someone writes a uint32 and you interpret it as an int32, it's possible that you interpret a very large positive number as a negative number (overflow).

size_t is just a typedef for an unsigned int, usually 32-bit I believe.

Answer 4

For most day-to-day programming, the size of an integer doesn't really matter all that much. But sometimes it is good to be specific. This is especially useful in low-level or embedded programming. Another place it is useful is scientific or computationally intensive tasks where it might be wasteful to use an int that is bigger than necessary.

The advantage of size_t is that it is unsigned. On the one hand it nice to use size_t because it adds more information about what the argument should be (i.e not negitave). On the other hand it is less tying vs. unsigned int.

Answer 5

The motivation to use them is because you can't rely on int, short or long to have any particular size - a mistake made by too many programmers far too many times in the past. If you look not too far back in history, there was a transition from 16 bit to 32 bit processors, which broke lots of code because people had wrongly relied on int being 16 bits. The same mistake was made thereafter when people relied on int to be 32 bits, and still do so even to this day.

Not to mention the terms int, short and long have been truly nuked by language designers who all decide to make them mean something different. A Java programmer reading some C will naively expect long to mean 64 bits. These terms are truly meaningless - they don't specify anything about a type, and I facepalm every time I see a new language released that still uses the terms.

The standard int types were a necessity so you can use the type you want to use. They should've deprecated int, short and long decades ago.