Re: [boost] Re: what happened to allocators in boost?

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-08-27 10:27:32

On Wednesday, Aug 27, 2003, at 05:21 America/Denver, Peter Dimov wrote:
> ...
> I say that the primary motivation to customize memory management 
> details is
> that the default memory manager is slow.

But not the only motivation.  Thread safety, lack of fragmentation,
predictability ...

> The standard allocators have a somewhat different story. They were
> originally intended to encapsulate the memory model, not the memory
> management details; this was in the near/far days. The original STL 
> did its
> own memory management (free lists) independent of the allocator 
> argument.
>
> Someone that has actually been present at the relevant meetings can 
> fill the
> details why the allocators are now what they are (I'm tempted to use
> Alexander Terekhov's favorite characterization here :-)).

As you state, they started out as a way of handling mixed memory
models.  They were soon discovered to be useful for other purposes,
including proxy pointers, but those uses put a lot of stress on the
exact semantics of allocators and containers, with different
implementors having made different choices (e.g. what happens if you
splice together lists with non-equal allocators).  We could not
resolve our differences, and settled for the special dispensations
and non-normative encouragement of the "Kona compromise" in 20.1.5:

    Implementations of containers described in this International
    Standard are permitted to assume that their Allocator template
    parameter meets the following two additional requirements beyond
    those in Table 32.
    — All instances of a given allocator type are required to be
    interchangeable and always compare equal to each other.
    — The typedef members pointer, const_pointer, size_type, and
    difference_type are required to be T*, T const*, size_t, and
    ptrdiff_t, respectively.

    Implementors are encouraged to supply libraries that can accept
    allocators that encapsulate more general memory models and that
    support nonequal instances. In such implementations, any
    requirements imposed on allocators by containers beyond those
    requirements that appear in Table 32, and the semantics of
    containers and algorithms when allocator instances compare
    nonequal, are implementation defined.

The first dispensation finesses the list splice problem, and the
second dispensation prohibits proxies, and then the encouragement
pretends to give back to users what the dispensations take away.  As
a result of this unfortunate muddle allocators are far less useful
than they might have been.  In my humble opinion, of course.

>> There can be an orthogonal need for a different allocator class, 
>> which no
>> improvement on the default one can fix.
>
> Oh yes, there "can be". And there "can be" a need for something else, 
> too.
>
>> In this case, the Java user is 100% screwed since they can't change
>> the memory manager at all. [...]
>
> My point exactly. This is why the Java memory manager beats C++'s 
> memory
> manager in the long run, because the user can't fix it.

So we Java implementors are forced to provide a high-quality memory
manager.  But if we mess up it is tough luck for our users, whereas
C++ users can always take over if they dare.