[boost] Re: Boost memory management guidelines

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-30 12:33:30

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.

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
and other language added to the standard later effectively killed any
possibility that they would work for different memory models.  Now
they're being bent to various other purposes.  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.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com