Re: [boost] Re: Boost memory management guidelines

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-09-02 13:34:23

On Tuesday, Sep 2, 2003, at 11:39 America/Denver, David Abrahams wrote:
> Gregory Colvin <gregory.colvin_at_[hidden]> writes:
>
>> On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams 
>> wrote:
> ...

> I think you're missing my point.  There's no reason that a stateful
> allocator<T> should have access to the state data required to
> allocate U objects, but that's the status quo.

I'm probably missing your point, but the idea is that a container
needs to allocate various kinds of things, and they all get
allocated with the same allocator, either directly or via rebind.

For instance, maybe you are are using memory-mapped files as a
persistent storage.  The Ts and the Us and whatever the container
needs all have to go into the same file, so the allocator<T> and
all its rebinds must know which file to use and how.

> ...
>>>   It's a conceptual mess.
>>
>> Alex didn't have MPL when he invented allocators.  So they are
>> messier than they need to be, but I still say they are not so
>> bad as you claim
>
> Are you saying my factual claims are wrong, or just that all those
> issues don't amount to a very important problem?

Just that it doesn't look nearly as messy to me as it does to you.

>> and that it would be easier for the next standard to repair them
>> than to replace them.
>
> That may be, but we're here at Boost, talking about the interface we
> should be using in Boost components.

Yep.  I still think UserAllocator is a good default, and that where it
doesn't suffice there is some value to playing nicely with STL.

So even when we come up with some beautiful new thing to do the
allocation job better, we will still need adaptors both ways, so that
one can get an allocator from an STL container and turn it in to one
of our new things, or take one of our new things and turn it into an
allocator to use in an STL container.