Proposal for std::vector.

[Matt Austern]

On Feb 9, 2004, at 2:30 PM, Gabriel Dos Reis wrote:

> Matt Austern <austern@apple.com> writes:
>
> | OK, I've analyzed your test program.  I'm not completely sure what 
> you
> | consider to be correct behavior.  I'm also not completely sure what
> | behavior really is correct here.
> |
> | What's going on: the test program involves a user-defined allocator
> | with a virtual member function clear().  It is crucial, for this 
> test,
> | that it is virtual.  Our std::vector inherits (privately) from its
> | allocator argument.  A consequence is that the compiler sees
> | std:;vector<T>::clear to be an override of the allocator's clear().
> |
> | Now we've got a member function of this allocator that, at one point,
> | calls this->clear().  This member function is called from within the
> | vector.  So this member function calls the vector's clear() instead 
> of
> | the allocator's clear().  The allocator's destructor also calls
> | this->clear() at one point.  In the context of the destructor this
> | means the allocator's clear(), not the vector's.
> |
> | So I think the fundamental question is: if a user provides a
> | user-defined allocator with a virtual member function that isn't part
> | of the standard's allocator interface, and the user performs a
> | polymorphic function call of that virtual member function, what 
> should
> | the user be entitled to expect?
>
> There is nothing in the standard requirements that prevents
> user-defined allocator to define -more- functions than listed.
>
> | This certainly is a test case that behaves differently depending on
> | whether the standard containers inherit privately from their
> | allocators.  If we think there shouldn't be any changes in behavior,
> | then we'll have to do something a bit more complicated than private
> | inheritance from allocators.
>
> Yup :-(

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.

Unless anyone has a solution they like better, I'll go ahead an generate
a patch.

			--Matt