From: John Max Skaller (skaller_at_[hidden])
Date: 2001-05-19 19:51:56
> John -
> > Unfortunately, the Standard allocator design is seriously
> > broken. I wonder if there is any interest in
> > a boost version of STL containers (and a version
> > of the default allocator) that fixes this problem.
> I agree with you that the Allocator requirements need some re-work. As you
> point out, the drawback is the inability of the Standard containers to work
> with instance-based Allocators.
> 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
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).
> 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.
-- John (Max) Skaller, mailto:skaller_at_[hidden] 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk