J
James Kanze
What isn't true, that the intent was that it should be the same
as size_type of the allocator, or that that's what most
implementations do. With regards to the implementations, there
does seem to be some differences: g++ and the STLPort use
size_t, but Dinkumware and Roguewave use allocator::size_type.
With regards to the "intent", it's very difficult to know what
the intent was behind anything to do with allocators, but if
there was no intent that the user could customize it, why the
typedef to begin with.
You mean paragraph 4. Then see paragraph 5. The whole thing is
a farce, of course---the standard says that it doesn't require
user supplied allocators to be useful for anything, then goes on
to say that the implementation is "encouraged" to make them
useful. At the time of standardization, there was considerable
discussion about allocators---a lot of people seemed to want
them, but for a lot a of different reasons. I can remember
hearing at least two justifications for this additional
complexity: to support different pointer sizes (i.e. far
pointers on an Intel at the time), and to support things like
putting containers in shared memory. A mimimum implementation
of the standard, i.e. one which takes full advantage of the
freedoms in 20.1.5/4, doesn't support either. Quality
implementations, such as Dinkumware, do take the statement of
intent in paragraph 5 seriously, however. (Whether this means
that you actually can use allocators to put a container in
shared memory, I really don't know. If not, however, then
allocators are just excess baggage.)
Anyway, with regards to my original statement: it should be
ammended to say that it's implementation defined whether
vector<T>::size_type can be anything the user wants, but the
standard explicitely "encourages" an implementation to support
this possibility.