[boost] Re: Boost memory management guidelines

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-30 14:18:24

Gregory Colvin <gregory.colvin_at_[hidden]> writes:

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

And so long as the implementation doesn't take advantage of the
weasel-wording about the assumptions on allocator's nested types.  Can
you tell me of any C++ implementations which will work with segmented
memory if I pass them a special allocator?

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

No, I mean "good old" Win16 segmented memory.

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

Or without getting all the functionality into allocators that
std::vector can use, or without pruning out functionality that no
standard component needs or uses, or...

Dude, no offense, but the allocator specification is a mess.  I'm not
saying the concept is way off base, but it's miles from being a
minimal, complete specification of a generally-useful allocation
interface.  See, for example, my recent questions on the -lib
reflector about reusing allocator.  What was it Pete said?  It was
something like "allocators are not a general-purpose memory management
tool.  They're specifically designed to work with containers."  I
don't even think they meet that design goal too well...

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