The names were taken from the POSIX specification, which was widely used before C and C++ standardised the names of fixed-size integer types. POSIX uses a convention of appending _t
to most type names.
uint32_t, int_t notation for representing variable size
-
16-06-2023 - |
Question
This question only is about the notation selection reason.
To prevent bugs it is essential to mention the variable size in bits like
uint32_t VariableA; // uint32_t has been type defined for architecture whose int size is 32 bit.
int16_t VariableB;
instead of using only type specifiers like
int VariableName;
The question here is why is _t used in the uint32_t instead of only uint32. Where did this _t come that has been seen appended in the typedef?
La solution
Autres conseils
The _t
convention comes from the early days of UNIX. Following suit, most (or all) aliases to scalar types and many struct
types in Posix are named as such, and some such types are even standardized in C itself.
Posix furthermore reserves all names suffixed with _t
in the C++ global namespace (or for C, just in general).
C++ does not introduce any new _t
names to my knowledge, and best-practice use of the C++ standard library only introduces names into the std
namespace.
At some point in the future, it is anticipated/hoped that Posix will be sandboxed in the posix
namespace.
In any case, best practice is to keep all your interface typedef
s in your own namespace, and once you've done that, naming aliases to scalar types with _t
is quite a reasonable policy. The benefit is that C++ is often sensitive to whether two name refer to types that are really different (but maybe behave similarly) or they are really aliases to the same thing. _t
is obviously an alias to something simple.
_t
basically denotes a type
name. Therefore, you would be ill-advised to end variable or function names with _t
since it could cause some confusion and even undefined behaviour(depending on compiler etc.)
Addendum
POSIX
systems define a lot of extra type names ending in _t
, and reserves the suffix for the implementation. Therefore when working on POSIX-related systems, defining your own type names with the convention is ill-advised and can lead to undefined behaviour