This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Proposal for std::vector.
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