size_type and size_t

[Jess]

Hello,

I think any specialized size_type, such as string::size_ty pe and
vector<T>::size _type, is defined in terms of size_t, which is much
more low level. Since they are more or less equivalent, what's the
advantage of using size_type over size_t?

Thanks,
Jess

[Fei Liu]

Jess wrote:

Hello,

I think any specialized size_type, such as string::size_ty pe and
vector<T>::size _type, is defined in terms of size_t, which is much
more low level. Since they are more or less equivalent, what's the
advantage of using size_type over size_t?

Thanks,
Jess

The problem is your premise, 'they are more or less equivalent', no,
they ain't equivalent at all. They are all highly
implementation/platform dependent.

F

[Default User]

Fei Liu wrote:

Jess wrote:

Hello,

I think any specialized size_type, such as string::size_ty pe and
vector<T>::size _type, is defined in terms of size_t, which is much
more low level. Since they are more or less equivalent, what's the
advantage of using size_type over size_t?

The problem is your premise, 'they are more or less equivalent', no,
they ain't equivalent at all. They are all highly
implementation/platform dependent.

No and yes. Here's what the standard says under

20 General utilities library

20.1.5 Allocator requirements

4 Implementations of containers described in this International
Standard are permitted to assume that their Allocator template
parameter meets the following two additional requirements beyond
those in Table 32.

— The typedef members pointer, const_pointer, size_type, and
difference_type are required to be T*,T const*, size_t, and
ptrdiff_t, respectively.
5 Implementors are encouraged to supply libraries that can accept
allocators that encapsulate more general memory models and that
support non-equal instances. In such implementations , any
requirements imposed on allocators by containers beyond those
requirements that appear in Table 32, and the semantics of
containers and algorithms when allocator instances compare
non-equal, are implementation-defined.


Brian

[James Kanze]

On May 22, 2:51 pm, Jess <w...@hotmail.c omwrote:

I think any specialized size_type, such as string::size_ty pe and
vector<T>::size _type, is defined in terms of size_t, which is much
more low level. Since they are more or less equivalent, what's the
advantage of using size_type over size_t?

In theory, or in practice?

In theory, vector and basic_string have an additional template
argument, which is an allocator. It defaults to the standard
allocator (so you don't have to specify it), and the standard
allocator is required to define size_type as size_t. But other,
user defined allocators can define it as something different.
(The size_type in vector and basic_string is just a typedef to
the type in the allocator.)

In practice, allocators are very subtle, not easy to use, and in
fact rarely used. Unless you're writing truly generic code, you
can generally ignore the issue, and just use size_t.

(I think that allocators were originally invented to support the
different types of pointers on a 16 bit Intel processor, so that
if e.g. you were compiling in small, with size_t a 16 bit
unsigned int, you could still declare a vector with an allocator
which used huge model, with 32 bit pointers and a 32 bit
unsigned long for size_type. In that context, they actually
make sense.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]