Re: Stateful allocators in libstdc++v [was: Re: Patch: stl_vector.h]

[Matt Austern <austern at apple dot com>]

On Oct 17, 2004, at 1:43 AM, Dhruv Matani wrote:

> On Sun, 2004-10-17 at 00:04, Matt Austern wrote:
> > On Oct 16, 2004, at 3:37 AM, Dhruv Matani wrote:
> >
> > > On an unrelated note, would we be interested in providing support for
> > > stateful allocators in gcc4?
> >
> > Don't we provide it already?  Perhaps you mean something by "support
> > for stateful allocators" than I do, but _Vector_base squirrels away a
> > copy of the allocator the user provided, all the allocator operations
> > dispatch to that copy, and get_allocator returns another copy of it.
> > To me that seems like we're preserving and using state.
>
> What I mean is different. ie. allocators which have "state", meaning
> that:
>
> allocator1<type> a;
> allocator1<type> b;
>
> a == b; // should not necessarily return true.
>
> So, consider:
>
> list<int, stateful_allocator<int> > l1;
> list<int, stateful_allocator<int> > l2;
>
> // Now splice should not work when you try to move around objects from
> l1 to l2 or vice-versa.

We already support allocators where l1.get_allocator() != 
l2.get_allocator().  What we don't do is make any special provisions to 
detect those allocators in splice() and swap().  (Splice is an issue 
for list only, of course, and swap is an issue for all containers.)

There has been longstanding disagreement about what those operations 
should mean in the case of non-equal allocators.  [Historical note: 
this is one reason that I opposed putting stateful allocators in the 
standard at all, back in '95.]  What to do about them is an open 
library issue: 
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431

My favorite solution is that splicing or swapping between containers 
with unequal allocators should be undefined behavior.  Howard Hinnant 
argues that swap should be defined and should swap both the contents 
and the allocators themselves.  (You may notice a potential 
complication with that solution...)

			--Matt