Boost logo

Boost :

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-08-30 14:59:16


On Saturday, Aug 30, 2003, at 13:18 America/Denver, David Abrahams
wrote:
> 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?

Dinkumware did then. Any library that targets real mode x86 still
does I'd bet. The weasel wording isn't a big issue here, because
near and far are already extensions.

> ...
> Dude, no offense, but the allocator specification is a mess.

Hey, I know -- I tried to help clean it up years ago. But I think
it is the spec that is a mess, not the concept or the decent
implementations I've seen.

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

I don't remember that discussion very well, but I remember I didn't
fully agree with Pete. It think you just had a hard problem to solve,
and it wasn't clear to me how allocators could be different in a way
that would have helped you.

And yes, allocators were designed for containers, but the needs of
containers are general enough that the allocator functionality is
also pretty general. They don't meet all needs, and I don't claim
they do, but I think there is a bit of unwarranted FUD in the idea
that they should be avoided or deprecated.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk