size_t and size_type

D

Denis Remezov

Grumble said:
What is the difference between size_t and vector<T>::size_type?

Are they ever a different type or a different size?

Why should one type the latter when the former is shorter?

What about the size_type type in other STL classes?


vector<T>::size_type is implementation-defined. The same holds for the
other standard containers. Generally, you cannot rely on it being size_t.
I've seen it defined (most commonly) as
typedef size_t size_type;

as well as
typedef _Allocator::size_type size_type;

where _Allocator was the container's allocator template parameter.
In the latter case you could actually end up getting it defined differently from
size_t (though the standard allocator defines size_type as size_t, there is no such
requirement for custom allocators).

I think you are better off using generic definitions (such as Container::size_type)
in generic code anyway, it makes it more generic (sorry for the wording).

Denis
 
G

Grumble

What is the difference between size_t and vector<T>::size_type?

Are they ever a different type or a different size?

Why should one type the latter when the former is shorter?

What about the size_type type in other STL classes?
 
D

Denis Remezov

John said:
Actually no, vector<T>::size_type uses the standard allocator, so its
size_type must be size_t.


But things get interesting when we consider custom allocators. Then you are
right that you cannot assume that vector<T, some_allocator>::size_type is
size_t. However the C++ standard explicitly gives permission of
implementations of the standard library to assume that vector<T,
some_allocator>::size_type is size_t (same goes for all the other
containers).

In other words you cannot pass an allocator to a standard library container
type that uses a size_type different from size_t and expect it to work.

Now that you've pointed that out I went back to the Standard and found clause
20.1.5.4. Amongst other things, it says that allocators for the _standard_
containers are required to define size_type as size_t. So I was wrong,
and you can assume size_type is size_t.


Denis
 
L

Leor Zolman

What is the difference between size_t and vector<T>::size_type?

This should really be in the FAQ.

Bottom line: /probably/ none. The Standard explicitly allows container
implementors to assume that the allocators they're handed (from which the
size_type typedef may be propagated to the clients of the container,
although I have library implementations that just hard-wire size_t for the
container typedefs) define size_type as size_t. Extensions are also
permitted (see 20.1.5/4).
Are they ever a different type or a different size?

If there are any such implementations, I don't know about them yet.
Why should one type the latter when the former is shorter?

Either they were thinking ahead to some scenario when containers' memory
would come from some heap with totally different rules of memory management
that needed its own unique size_type, or else this is just an artifact of
the Intel segmented architecture memory-model that influenced the creation
of allocators in the first place. Who knows...
What about the size_type type in other STL classes?

Same deal, AFAIK.
-leor
 
J

John Harrison

Denis Remezov said:
vector<T>::size_type is implementation-defined. The same holds for the
other standard containers. Generally, you cannot rely on it being size_t.

Actually no, vector<T>::size_type uses the standard allocator, so its
size_type must be size_t.

But things get interesting when we consider custom allocators. Then you are
right that you cannot assume that vector<T, some_allocator>::size_type is
size_t. However the C++ standard explicitly gives permission of
implementations of the standard library to assume that vector<T,
some_allocator>::size_type is size_t (same goes for all the other
containers).

In other words you cannot pass an allocator to a standard library container
type that uses a size_type different from size_t and expect it to work.

I imagine that this strange get out clause for the standard library
implementors was so that existing implementations were not invalidated (but
that's only a guess).

john
 
D

Denis Remezov

Denis said:
Now that you've pointed that out I went back to the Standard and found clause
20.1.5.4. Amongst other things, it says that allocators for the _standard_
containers are required to define size_type as size_t. So I was wrong,
and you can assume size_type is size_t.

Denis

However, on yet another thought, are the standard containers required to
define size_type as any specific type, either directly or through their
allocators? If not (I couldn't find anything to that effect) then
StdContainer::size_type is still implementation-defined (at least in theory).

Denis
 
J

John Harrison

Now that you've pointed that out I went back to the Standard and found clause
20.1.5.4. Amongst other things, it says that allocators for the _standard_
containers are required to define size_type as size_t. So I was wrong,
and you can assume size_type is size_t.

Perhaps the language isn't the best but that's not how I read it.

To me 20.1.5.4 says

Implementers of containers ... are permitted to assume ... that the typedef
member ... size_type is required to be size_t.

In other words implementers of the standard library are permitted to make
the requirement, but the standard itself is not making that requirement.

At least that's how I read it.

john
 
A

Alf P. Steinbach

* "John Harrison said:
Perhaps the language isn't the best but that's not how I read it.

To me 20.1.5.4 says

Implementers of containers ... are permitted to assume ... that the typedef
member ... size_type is required to be size_t.

In other words implementers of the standard library are permitted to make
the requirement, but the standard itself is not making that requirement.

At least that's how I read it.


Statically assert that the type is size_t and be done with it -- simply
adding the requirement that the *¤/&#&! standard lacks.
 
J

Jeff Schwab

Grumble said:
What is the difference between size_t and vector<T>::size_type?

Are they ever a different type or a different size?

Why should one type the latter when the former is shorter?

What about the size_type type in other STL classes?


Use typename Container::size_type in generic code, even when Container
happens to be an instantiation of the vector class template. This will
help you can switch container types without too much pain. I speak from
experience.
 
P

Pete Becker

Leor said:
Either they were thinking ahead to some scenario when containers' memory
would come from some heap with totally different rules of memory management
that needed its own unique size_type, or else this is just an artifact of
the Intel segmented architecture memory-model that influenced the creation
of allocators in the first place. Who knows...

I do. <g> If you have ancient copies of the STL documentation from HP,
you'll see my name listed as one of the contributors. That's because I
"fixed" a problem that Alex Stepanov and Meng Lee had in specifying
allocators. They were dealing specifically with the Intel architecture,
but that was just a particular instance of a more general problem. So
the true answer is that both of your alternatives are correct: size_type
is there for the Intel segmented architecture in particular, and for
alternative memory managers in general.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Staff online

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top