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
> > 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:
> 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:
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
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk