If you care about 'the law' as laid out by the offical C++ standard then yes, it is bad to use
::size_t) can only be reliably included from
<stddef.h> (and its relatives).
<cstddef> (and its relatives) will only guarantee the inclusion of
::std::size_t), it will not guarantee the inclusion of
As of C++11
<stddef.h> (and its relatives) is deprecated, which means that the only means of acquiring
size_t in the global namespace without explicitly bringing it into the global namespace (e.g. via
using std::size_t;) is deprecated.
Deprecated library features could be removed in any future version of the standard library (and indeed some have been in the past), so it is bad practice to use deprecated features if you can avoid doing so.
Furthermore if you are using
<cstddef> (or its relatives) and expecting to get
size_t then your code is technically not standard C++ because it is relying on an implementation-specific detail.
To quote cppreference:
For some of the C standard library headers of the form
xxx.h, the C++ standard library both includes an identically-named header and another header of the form
cxxx (all meaningful
cxxx headers are listed above).
With the exception of
complex.h , each
xxx.h header included in the C++ standard library places in the global namespace each name that the corresponding
cxxx header would have placed in the
These headers are allowed to also declare the same names in the
std namespace, and the corresponding
cxxx headers are allowed to also declare the same names in the global namespace: including
<cstdlib> definitely provides
std::malloc and may also provide
<stdlib.h> definitely provides
::malloc and may also provide
std::malloc. This applies even to functions and function overloads that are not part of C standard library.
stdnamespace, but I'm yet to see any project that does consistent use the
std::prefix for C-library calls.