Re: [boost] Re: Boost memory management guidelines

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-08-30 13:04:18

On Saturday, Aug 30, 2003, at 11:33 America/Denver, David Abrahams 
wrote:
> Howard Hinnant <hinnant_at_[hidden]> writes:
>
>> On Saturday, August 30, 2003, at 10:45 AM, Peter Dimov wrote:
>>
>>> On the other hand, the alternative seems reasonable, too. The
>>> allocator is
>>> part of the state (accessor is available), therefore after v1 = v2
>>> v1 holds
>>> a2. If I want to retain the allocator I can use
>>>
>>> v1.assign(v2.begin(), v2.end());
>>>
>>> which works for any v2, not just the specific vector<T, A>.
>>
>> The reason that this doesn't seem reasonable to me is that allocator
>> state is not used in comparing the state of the vectors.  That is, in
>> v1 == v2, the state of the allocator is ignored.
>
> Doesn't the unequal allocator weasel-wording allow implementations to
> account for the allocator state in v1 == v2 if they so choose?
>
>> Therefore it seems to me that the only reason for the existence of
>> allocator state is to control the allocation and deallocation of
>> internally allocated memory. Therefore any internally allocated
>> memory, coupled with the allocator that allocated said memory, is
>> effectively (or should be) an atomic unit, never to be split apart.
>
> Oh sure, I agree.  But the weasel-wording also allows you to
> completely reallocate the memory with the new allocator in case of
> unequal allocators, too.

Right.  The weasel wording says that if allocators of the same
type compare unequal then all bets are off.

> I'm not saying these are good choices.  My main contention is that we
> committed a minor crime in enshrining allocators as we did: they were
> invented to handle different memory models; they didn't work for that

Yes, they did, and do, work for that, so long as the memory model
doesn't require proxy pointers.  But working for "near" and "far"
isn't so important as it used to be.

> and other language added to the standard later effectively killed any
> possibility that they would work for different memory models.

By "different memory models" do you mean proxy pointers?  If so, yes
we did damage that, which remains unfortunate.

>   Now they're being bent to various other purposes.

They had already been successfully bent to other purposes, such as
proxy pointers for persistent stores and shared memory, at the time we
weaseled.  And that success was a good indication that the allocator
requirements had done a good enough job of capturing the concept of a
memory model, enough so that in some implementations proxy pointers
"just worked".

>   We didn't know what we
> were doing in the first place and shouldn't keep pressing the
> allocator concept into everything until we know what we're really
> after.

I think we knew what we were doing.  We just ran out of time without
managing to reconcile divergent existing practice on how containers
should handle allocator state, or to fully specify the semantics of
proxy pointers.