[boost] Re: Boost memory management guidelines

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
www.boost-consulting.com