Proposal for std::vector.

[Stephen M. Webb]

On Friday, February 06 2004 10:09, Dhruv Matani wrote:
> On Fri, 2004-02-06 at 19:21, Stephen M. Webb wrote:
> > On Friday, February 06 2004 07:51, Dhruv Matani wrote:
> > > The relevant discussion can be found by searching google for:
> > > About std::vector and standard containers in general.
> > >
> > >
> > > Wierd as it may seem, are standard containers such as std::vector
> > > allowed
> > > to derive from std::allocator, or more generally from an allocator
> > > class?
> >
> > Some implementations do this.  Vector is the trivial case.  Consider what
> > you would do with deque and map.
>
> Leave them as they are because they would probably not be using
> stateless allocators.

Deque is no less likely to use a stateless allocator than is vector.

Since all the containers use std::allocator by default, unless you're planning 
on changing std::allocator to specialize it for the various standard 
containers, the "normal" usage for all containers is the same.

Consider that all of the associative containers and all of the sequence 
containers save std::vector (not specialized for bool) need to rebind their 
allocators.

I'm not saying it's impossible to base the standard containers on their 
allocators to take advantage of the EBCO -- I've done it and got it working, 
for std::list at least.  I'm saying consider the impact in terms of code 
complexity for those containers (it increases) and readability (it decreases) 
vs. size or speed advantages (I couldn't measure anything significant).

Your results may differ.  I would be pleased to review them.

-- 
Stephen M. Webb
stephen.webb@bregmasoft.com