Proposal for std::vector.

[Gabriel Dos Reis]

Matt Austern <austern@apple.com> writes:

| 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.

Aha, thanks!  Since we're introducing an aggregation in the middle,
why do we use inheritance in the end?  Do you think there still is an
opportunity for empty base class optimization here?

-- Gaby