From Wikipedia
The
stdlib.h
andstddef.h
header files define a datatype calledsize_t
1 which is used to represent the size of an object. Library functions that take sizes expect them to be of typesize_t
, and the sizeof operator evaluates tosize_t
.The actual type of
size_t
is platform-dependent; a common mistake is to assumesize_t
is the same as unsigned int, which can lead to programming errors,2 particularly as 64-bit architectures become more prevalent.
From C99 7.17.1/2
The following types and macros are defined in the standard header
stddef.h
<snip>
size_t
which is the unsigned integer type of the result of the sizeof operator
This way you always know what the size is, because a specific type is dedicated to sizes. The very own question shows that it can be an issue: is it an int
or an unsigned int
? Also, what is the magnitude (short
, int
, long
, etc.)?
Because there is a specific type assigned, you don't have to worry about the length or the signed-ness.
The actual definition can be found in the C++ Reference Library, which says:
Type:
size_t
(Unsigned integral type)Header:
<cstring>
size_t
corresponds to the integral data type returned by the language operatorsizeof
and is defined in the<cstring>
header file (among others) as an unsigned integral type.In
<cstring>
, it is used as the type of the parameternum
in the functionsmemchr
,memcmp
,memcpy
,memmove
,memset
,strncat
,strncmp
,strncpy
andstrxfrm
, which in all cases it is used to specify the maximum number of bytes or characters the function has to affect.It is also used as the return type for
strcspn
,strlen
,strspn
andstrxfrm
to return sizes and lengths.
According to size_t description on en.cppreference.com size_t
is defined in the following headers :
std::size_t
...
Defined in header <cstddef>
Defined in header <cstdio>
Defined in header <cstring>
Defined in header <ctime>
Defined in header <cwchar>
Practically speaking size_t
represents the number of bytes you can address. On most modern architectures for the last 10-15 years that has been 32 bits which has also been the size of a unsigned int. However we are moving to 64bit addressing while the uint
will most likely stay at 32bits (it's size is not guaranteed in the c++ standard). To make your code that depends on the memory size portable across architectures you should use a size_t
. For example things like array sizes should always use size_t
's. If you look at the standard containers the ::size()
always returns a size_t
.
Also note, visual studio has a compile option that can check for these types of errors called "Detect 64-bit Portability Issues".
I'm not familiar with void_t
except as a result of a Google search (it's used in a vmalloc
library by Kiem-Phong Vo at AT&T Research - I'm sure it's used in other libraries as well).
The various xxx_t typedefs are used to abstract a type from a particular definite implementation, since the concrete types used for certain things might differ from one platform to another. For example:
Void_t
abstracts the type of pointer returned by the vmalloc
library routines because it was written to work on systems that pre-date ANSI/ISO C where the void
keyword might not exist. At least that's what I'd guess.wchar_t
abstracts the type used for wide characters since on some systems it will be a 16 bit type, on others it will be a 32 bit type.So if you write your wide character handling code to use the wchar_t
type instead of, say unsigned short
, that code will presumably be more portable to various platforms.
In minimalistic programs where a size_t
definition was not loaded "by chance" in some include but I still need it in some context (for example to access std::vector<double>
), then I use that context to extract the correct type. For example typedef std::vector<double>::size_type size_t
.
(Surround with namespace {...}
if necessary to make the scope limited.)
size_t should be defined in your standard library's headers. In my experience, it usually is simply a typedef to unsigned int. The point, though, is that it doesn't have to be. Types like size_t allow the standard library vendor the freedom to change its underlying data types if appropriate for the platform. If you assume size_t is always unsigned int (via casting, etc), you could run into problems in the future if your vendor changes size_t to be e.g. a 64-bit type. It is dangerous to assume anything about this or any other library type for this reason.
As for "Why not use int or unsigned int?", simply because it's semantically more meaningful not to. There's the practical reason that it can be, say, typedef
d as an int
and then upgraded to a long
later, without anyone having to change their code, of course, but more fundamentally than that a type is supposed to be meaningful. To vastly simplify, a variable of type size_t
is suitable for, and used for, containing the sizes of things, just like time_t
is suitable for containing time values. How these are actually implemented should quite properly be the implementation's job. Compared to just calling everything int
, using meaningful typenames like this helps clarify the meaning and intent of your program, just like any rich set of types does.
size_t
is the unsigned integer type of the result of the sizeof operator (ISO C99 Section 7.17.)
The sizeof
operator yields the size (in bytes) of its operand, which may be an
expression or the parenthesized name of a type. The size is determined from the type of
the operand. The result is an integer. The value of the result is implementation-de?ned, and
its type (an unsigned integer type) is size_t
(ISO C99 Section 6.5.3.4.)
Source: Stackoverflow.com