Difference Between Size_T and Std::Size_T

Difference between size_t and std::size_t

C's size_t and C++'s std::size_t are both same.

In C, it's defined in <stddef.h> and in C++, its defined in <cstddef> whose contents are the same as C header (see the quotation below). Its defined as unsigned integer type of the result of the sizeof operator.

C Standard says in §17.7/2,

size_t which is the unsigned integer type of the result of the sizeof operator

And C++ Standard says (about cstddef header) in §18.1/3,

The contents are the same as the Standard C library header , with the following changes.

So yeah, both are same; the only difference is that C++ defines size_t in std namespace.

Please also notice that the above line also says "with the following changes" which isn't referring to size_t. Its rather referring to the new additions (mostly) made by C++ into the language (not present in C) which are also defined in the same header.

Wikipedia has very good info about range and storage size of size_t:

Range and storage size of size_t

The actual type of size_t is
platform-dependent; a common mistake
is to assume size_t is the same as
unsigned int, which can lead to
programming errors,[3][4] when moving
from 32 to 64-bit architecture, for
example.

According to the 1999 ISO C
standard (C99), size_t is an unsigned
integer type of at least 16 bits.

And the rest you can read from this page at wikipedia.

What to do with size_t vs. std::size_t?

You should specify it with the using directive.

using std::size_t;

Add it either to the global scope of each compilation unit, or to the local scopes if it would cause interference at the global scope.

stddef.h also works, as you noted, and honestly that method is not "worse" than this one. However, stddef.h is a backwards compatibility header, and it might be best to avoid relying on it in new code.

I prefer the using directive because it does not pollute the global namespace anywhere you don't need to, and does not rely on arbitrary compiler support of nonstandard behavior. Further, this is the generally accepted way to bring a type into a namespace when multiple options are otherwise possible, so it is not unique to the usage of size_t.

This isn't really something that a person can authoritatively answer. I've been a professional developer for 10 years, and have worked with C++ since 1998, but I will never see any statistically significant portion of the total C++ code that's been written. From what I have seen, there is plenty of code out there that still uses stddef.h, and it won't likely break anytime soon.

For new code, I prefer just typing the "std::" prefix everywhere, only applying the using directives when it becomes cumbersome or difficult to read. However, I recognize that this can be irritating for "inherited" code, which is where the file-scope using directives are better. If you have the time to properly refactor the inherited code, there's a good argument that you should do so, but it's very likely to involve more than just the size_t variables.

I should also mention that the C++ FAQ (item 27.5) mentions this concern as well here, where I got the impression they mostly recommend consistency with others on your team.

I want to note here that it is NOT good practice to apply "using namespace std" at the file scope, though this would also bring size_t into the global namespace. I will link the reason for that here.

I seem to have scared tuple_cat off (sorry), but I really did think his empirical method was good, so I'm trying to incorporate some changes to resolve my concerns with his answer. I tried searching github with the following modified queries, which admittedly still may have some issues:

A) "size_t" AND "stddef.h" language:c++
B) "std::size_t" AND "<cstddef>" language:c++
C) "size_t" AND "<cstddef>" AND NOT "std::size_t" language:c++
D) "size_t" AND "<cstddef>" AND "using namespace std" AND NOT "std::size_t" language:c++
E) "size_t" AND "<cstddef>" AND "using std::size_t" language:c++

I get the following:

A) 974,239 results (stddef.h approach)
B) 1,230,021 results (cstddef approach, with "std::" prefixes)
C) 469,721 results (cstddef approach, no prefixes)
D) 32,539 results (cstddef approach, "using namespace std", DON'T DO THIS!)
E) 27,080 results (method I recommend, "using std::size_t")

It's definitely not perfect, and I welcome criticism to make it better, but it appears that the method I recommend, as stated, is not the most popular. Based on the data, it appears that the most popular is using the "std::" prefixes on size_t (B), followed by including "stddef.h" (A). Luckily, the bad approach of (D) is not popular, but it appears that many people may be relying on other files/headers to bring size_t into the global namespace, or just hoping it's already there on the compiler (C).

Therefore, to "go with the herd", you should prepend everything with "std::". If you don't want to do that, then "stddef.h" is also in very common use, but my preference is still the using directive.

std::size_t vs size_t vs std::string::size_type

Where does size_t come from when I don't have anything included in an empty project?

If you don't have anything included, then you can't use size_t. It's defined in <stddef.h> (and perhaps also in <cstddef>, if your version of that header puts the definitions in the global namespace as well as std).

Is it reasonable to always assume size_t == std::size_t?

Yes. All types and functions defined by the C library are included in the std namespace, as long as you include the appropriate C++ header (e.g. <cstddef> rather than <stddef.h>)

When should I use std::_::size_type?

Do you mean the size_type types defined in some standard classes and templates such as vector? You could use those when using those classes if you like. In most cases, you'll know that it's the same as size_t, so you might as well use that and save a bit of typing. If you're writing generic code, where you don't know what the class is, then it's better to use size_type in case it's not compatible with size_t.

For example, you might want to write a container designed to hold more items than can be represented by size_t. You might use some kind of big number type to represent the container's size, which isn't convertible to size_t. In that case, code like size_t s = c.size() would fail to compile - you'd need to use Container::size_type instead.

Does std::size_t make sense in C++?

There seems to be confusion among the stackoverflow crowd concerning this

::size_t is defined in the backward compatibility header stddef.h . It's been part of ANSI/ISO C and ISO C++ since their very beginning. Every C++ implementation has to ship with stddef.h (compatibility) and cstddef where only the latter defines std::size_t and not necessarily ::size_t. See Annex D of the C++ Standard.

Why can I use size_t and std::size_t in MSVS without the traditional headers?

Strictly speaking your code is illegal. The size_t type is required to be declared in the following headers:

<cstddef>
<cstdio>
<cstdlib>
<cstring>
<ctime>
<cwchar>

But also the standard allows standard headers to include other standard headers. So most likely the header <vector> in the standard library used by MSVC includes one of the headers above. This is allowed, but not mandated by the standard so this will work on your setup, but can fail to work on other standard library implementations, even on a future version of the same one you are using.

So in conclusion try to include all the headers required by the standard for all the definitions you are using.

IMHO this is a faulty behavior, but is the required price C++ pays for backward compatibility to the inclusion system that seemed a reasonable design many years ago. The limitations and drawbacks of this are well known today and so the committee is working on modules, which is a modern alternative to the current inclusion mechanism.

As to why you can use size_t without std:::

<cstddef> is required to declare std::size_t and may also optionally declare (or bring in the declaration of) size_t in the global scope.

<stddef.h> is a C backward compatible header and it declares size_t at the global scope.

So either <cstddef> declares size_t at a global level and is included by <vector> or <stddef.h> is included by <vector> - most likely indirectly via <cstddef>.

https://stackoverflow.com/a/283023/2805305

std::size_t vs. size_type as parameters and function return types

but of course there's the off-chance that the size of the vector isn't of type std::size_t

Such off-chance doesn't practically exist in this case because std::vector<MyClass*>::size_type is (indirectly guaranteed and required to be) of type std::size_t. Using std::size_t is fine in this case, and it doesn't leak unnecessary implementation details.

In the case of standard containers, Container::size_type is defined based directly on on what allocator is being used. Thus, using size_type is typically only necessary when the allocator type - or the container type itself - is templated. In the allocator case, you can use allocator traits instead of the container member type which allows you to keep the container type hidden. If the container type itself is templated, then there is no point in hiding it since only someone who knows the container could have instantiated the template in the first place.

Furthermore, you can hide - or rather obfuscate (in a positive, encapsulating way) - the function declaration by creating a type alias member, just like std::vector has a type alias member based on its allocator.

Example:

template<class Alloc>
class Foo
{
    // could be hidden with PIMPL if desired
    std::vector<MyClass*, Alloc> m_myVector;

public:
    // Since C++11
    using size_type = typename std::allocator_traits<Alloc>::size_type;
    // Prior to C++11
    typedef typename Alloc::size_type size_type;
    
    size_type size();
};

When to use std::size_t?

A good rule of thumb is for anything that you need to compare in the loop condition against something that is naturally a std::size_t itself.

std::size_t is the type of any sizeof expression and as is guaranteed to be able to express the maximum size of any object (including any array) in C++. By extension it is also guaranteed to be big enough for any array index so it is a natural type for a loop by index over an array.

If you are just counting up to a number then it may be more natural to use either the type of the variable that holds that number or an int or unsigned int (if large enough) as these should be a natural size for the machine.

What's the difference between size_t and int in C++?

From the friendly Wikipedia:

The stdlib.h and stddef.h header files define a datatype called size_t which is used to represent the size of an object. Library functions that take sizes expect them to be of type size_t, and the sizeof operator evaluates to size_t.
The actual type of size_t is platform-dependent; a common mistake is to assume size_t is the same as unsigned int, which can lead to programming errors, particularly as 64-bit architectures become more prevalent.

Also, check Why size_t matters

Where is size_t Defined?

I presume this technically means that the definition of size_t in the global namespace has been deprecated?

Yes... but.

The Standard only mandates that std::size_t must be defined¹ by <cstddef>, it does not disallow an implementation to define ::size_t², but if the implementation does, the two definitions must match³.

As a conclusion, you should use std::size_t and should neither rely on ::size_t to be defined nor define it.

The following are UB:

// DON'T
using size_t = std::size_t;        // UB
using size_t = decltype(sizeof 1); // UB

¹⁾ [cstddef.syn]

namespace std {
    using ptrdiff_t = see below;
    using size_t = see below;
    using max_align_t = see below;
    using nullptr_t = decltype(nullptr);
[...]

The contents and meaning of the header <cstddef> are the same as the C standard library header <stddef.h>, except that it does not declare the type wchar_t, that it also declares the type byte and its associated operations ([support.types.byteops]), and as noted in [support.types.nullptr] and [support.types.layout].

²⁾[extern.types]/1

For each type T from the C standard library (These types are [...] size_t,[...].), the types ::T and std::T are reserved to the implementation[.]

³⁾[extern.types]/1

[...] when defined, ::T shall be identical to std::T.

Difference Between Size_T and Std::Size_T