Boost logo

Boost :

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-05-19 19:51:56

scleary_at_[hidden] wrote:
> 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
> 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).
> 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
download Interscript

Boost list run by bdawes at, gregod at, cpdaniel at, john at