RE: [boost] Boost: containers and allocators

From: scleary_at_[hidden]
Date: 2001-05-21 14:22:10

John Max Skaller [skaller_at_[hidden]] wrote:
> scleary_at_[hidden] wrote:
> > Your copy<U> fix is not necessary, though; just use the envelope/letter
> > idiom (i.e., have an ActualAllocator class, and make your Allocator
class be
> > a sort of ref-counted pointer or something to reference the underlying
> > ActualAllocator).
> 
> 	That clearly doesn't work. How does the default
> constructor get hold of that pointer in the expression:
> 
> 	A.rebind<T>()
> 
> Note that 'rebind<T>' is a TYPENAME. This is wrong.
> A method is required to pass data from A to the new
> instance (by invoking some non-standard constructor).
> 
> I note that respecifying 'rebind' as a method will solve
> the problem for most uses of it, but that will 
> break code that might legitimately want the typename.
> 
> Eliminating any requirement for a default constructor
> is mandatory: a per instance allocator often CANNOT be
> default constructed (because it requires instance data).

What I meant is that current Allocators can be copy-constructed across
underlying types; that is:
  Allocator A1;
  typename Allocator::template rebind<list_node<T> >::other A2(A1);
is perfectly legal, which removes the need for a copy<T>() function.

I agree with you that default constructors shouldn't be required.

> > Also, there are problems with requiring all Standard containers to
accept
> > instance-based Allocators, even with empty base optimization -- the
> > canonical example is "how do you support std::list::splice?"
> 
> 	No problem. The existing words permit the Standard
> Library to assume allocators are 'compatible'. That means
> if YOU, the programmer, splice two lists which use
> incompatible allocators, it is YOUR problem.

OK, I can go with this.  But that *has* to be spelled out in the Standard
exactly when it could be a problem -- right now, *all* containers can make
that assumption *all* the time...

It would probably be nice to have an allocator_traits of some kind, which
could specify if the allocator is instance-based or not.  This would allow
such usage errors to be caught at compile-time.

        -Steve