Menu
Or can it be a separate unsigned integer type?
I have different specializations of a template function for different (unsigned) integer types. Do I need to provide a separate specialization for size_t?
570
Yes, size_t is guaranteed to be an unsigned type.
On a typical 64-bit system, the size_t will be 64-bit, but unsigned int will be 32 bit. So we cannot use them interchangeably. One standard recommendation is that the size_t be at most as big as an unsigned long.
size_t type is a base unsigned integer type of C and C++ language. It is the type of the result returned by sizeof operator. The type's size is chosen so that it can store the maximum size of a theoretically possible array of any type. On a 32-bit system size_t will take 32 bits, on a 64-bit one 64 bits.
When writing C code you should always use size_t whenever dealing with memory ranges. The int type on the other hand is basically defined as the size of the (signed) integer value that the host machine can use to most efficiently perform integer arithmetic.
The C++ Standard says:
18.2/2 The contents are the same as the Standard C library header , with the following changes:
18.2/6 The type size_t is an implementation-defined unsigned integer type that is large enough to contain the size in bytes of any object.
18.2/7 [ Note: It is recommended that implementations choose types for ptrdiff_t and size_t whose integer conversion ranks (4.13) are no greater than that of signed long int unless a larger size is necessary to contain all the possible values. —end note ]
So, it doesn't say explicitly whether the implementation-defined unsigned integer type will be one of unsigned short, int, long, long long. The fact that 18.2/6 exists and specifies an "implementation-defined unsigned integer type" may be seen to override 18.2/2's default of following C, so any answer for C can't be trusted for C++.
The recommendation re conversion ranks implies the size_t will be expected to be one of the types mentioned in 4.13, where size_t isn't explicitly mentioned but the obvious candidates are, but that's no guarantee.
Do I need to provide a separate specialization for size_t?
You could use std::is_same and std::enable_if to do so when size_t is a distinct type....
171
Text from [support.types]:
The contents are the same as the Standard C library header , with the following changes:
The type size_t is an implementation-defined unsigned integer type that is large enough to contain the size in bytes of any object.
From the C99 specification of stddef.h there is also this footnote for clarification:
224) Some of these types may denote implementation-defined extended integer types.
Since the C++ standard text does not specifically say that size_t must be a typedef, and since it appears to be based on C99, it seems to me that we should conclude that it may be an implementation-defined extended integer type.
Having said that, I don't know of any implementation for which it is not a typedef.
I'm not sure what you should do about your overload problem, however note that it is not limited just to size_t; there is also ptrdiff_t, and all of the fixed-width integer types. The latter are specified as being typedefs, however they are allowed to be aliases for extended integer types.
31
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
