[boost] Re: Boost memory management guidelines

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2003-08-30 13:13:28

On Saturday, August 30, 2003, at 1:33 PM, David Abrahams wrote:

>> 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?

I suppose it could.  On the one hand, the standard says exactly what 
v1==v2 means:

    v1.size()==v2.size() && equal(v1.begin(), v1.end(), v2.begin())

On the other hand the standard says all bets are off if allocators 
don't compare equal.  Taking this logic to its extreme might even allow 
insert to erase elements (the entire container universe is now 
implementation defined).

As a vendor, I think my customers would be surprised if insert suddenly 
had completely different semantics when allocators compared unequal.  
container==container seems only slightly less black and white to me.  I 
see no strong motivation to include the allocator as part of the 
comparable container state.   And I see even less motivation to 
silently turn v1.swap(v2) into an O(N) operation when allocators 
compare unequal.  Kind of like list::size : I would rather get a 
compile time error than have what I thought was O(1) go to O(N).  
Obviously opinions differ.  Some see automatic migration from O(1) to 
O(N) as a way to gracefully deal with less than ideal conditions.

> 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.

Well said.

-Howard