Proposal for std::vector.

[Gabriel Dos Reis]

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 :-(

-- Gaby