Proposal for std::vector.

[Magnus Fromreide]

On Mon, 9 Feb 2004, it was written:

> Date: Mon, 9 Feb 2004 20:53:43 -0800
> From: Matt Austern <austern at apple dot com>
> To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
> Cc: Dhruv Matani <dhruvbird at gmx dot net>,
>      libstdc++ <libstdc++ at gcc dot gnu dot org>
> Subject: Re: Proposal for std::vector.
>
> On Feb 9, 2004, at 6:20 PM, Gabriel Dos Reis wrote:
>
> > Matt Austern <austern@apple.com> writes:
> >
> > | I'm afraid you're right too.  Fortunately, I really do only mean "a
> > | bit" more
> > | complicated.  The solution is pretty simple: instead of inheriting
> > | directly
> > | from the allocator, instead inherit from a thin wrapper class that
> > | provides
> > | nothing but the allocator functions we care about.
> >
> >
> > Just to make sure I understand your suggestion.  In doing so, how do
> > we prevent the "virtual function is a sin you inherit from your
> > descendents" syndrom and benefit at the same time from the empty base
> > optimization?
> >
> > The solution I'm thinking of would be:
> >
> >   template<class Allocator>
> >     WrapAllocator {
> >        Allocator allocator;
> >        // standard allocator interface goes here
> >        // as forwarding functions to Allocator
> >        // ...
> >     };
> >
> >   template<class T, class Allocator = allocator<T> >
> >     struct vector : private WrapAllocator<Allocator> {
> >       // ...
> >     };
> >
> > Is that what you're alluding to?
>
> Basically, yes.  The two ways in which this isn't *exactly* what I
> have in mind:
>   (1) It won't be the full standard allocator interface, only the
>       useful part.  (i.e. "allocate" and "deallocate".)
>   (2) Two template parameters, not one.  As long as we have to
>       introduce this wrapper class anyway, may as well make it
>       do double duty by having it take care of the icky rebind
>       stuff.
>
> 			--Matt

Silly question:

As WrapAllocator is nonempty, wouldn't that kill the empty base
optimization and then we could just as well put allocator in vector
and be done with it?