This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Proposal for std::vector.
On Tue, 2004-02-10 at 10:23, Matt Austern wrote:
> 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;
How would this aid EBO?
IMHO, the good things about EBO would be lost as soon as the member
variable is introduced.
> > // 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
>
>
>
--
-Dhruv Matani.
http://www.geocities.com/dhruvbird/