Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at