Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-30 17:17:55

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

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

It's simple; allocators are limited to allocating chunks in multiples
of sizeof(T) with alignment in multiples of alignment_of(T). I needed
to allocate a chunk of N bytes with alignment suitable for T.
Low-level allocation interfaces like operator new and malloc will give
me chunks with universal alignment, and they make it easy to carve N
bytes out that I can stick any T into the beginning of, so there's
something wrong when a high-level allocator interface makes that
damn-near impossible.

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

Sorry, I think it is warranted. The low-level interfaces are easier
to understand and use correctly (**). If I have to get a job done
quick and right I'll reach for those. If I need to use allocators I'm
likely to have to spend at least an hour with the standard making sure
I understand the implications of what I'm doing.

(**) Here's another example: you have to tell allocators how much
memory you're deallocating. What's that all about?

Dave Abrahams
Boost Consulting

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