Re: [boost] Boost memory management guidelines

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-08-29 20:45:02

On Friday, Aug 29, 2003, at 18:05 America/Denver, David Abrahams wrote:
> Gregory Colvin <gregory.colvin_at_[hidden]> writes:
>
>> * use the standard parameterization mechanisms (Allocator) when
>>    choosing to parameterize
>
> I'm not sure about this one.  std::allocator are a mess, and almost
> everyone knows it.  They were designed for containers, and they only
> barely work there, IMO.

IMO they work just fine, and are not so messy as "everyone" thinks.
The only real ugliness is rebind, but without template typedefs there
isn't much choice.  And the only really missing functionality is
reallocation, but one can usually do without that.  They can be
difficult to implement well, but I think that is separate issue.

>   Remember the weasel-wording about unequal
> allocators and the assumptions implementations are allowed to make
> about allocator's nested types?

Remember it?  I helped write it.  It's unfortunate, as I explained
earlier in this thread, but clear enough.  It mainly serves to give
implementors more latitude in how they implement their containers,
and thus to give users fewer guarantees that fancy allocators will
work.

>  I really don't want to be in the
> position of forcing library authors to match users' expectations about
> the way their particular implementation's allocators work.

No force here.  If you choose to take any kind of template parameters
you should be clear what you require of them, and where the standard
provides a useable set of requirements it makes sense to point to them.
But if you need something different then by all means specify what you
need.

And I wasn't aware that there was that much variation in std::allocator
functionality, though I know there is some variation in whether the
standard containers support stateful allocators and proxy pointers.

 From my point of view, by choosing the standard Allocator interface you
get:
* a standard set of requirements, with a few levels of strictness to
   choose from
* a usually high-quality standard implementation (std:allocator)
* a high quality Boost implementation (boost::pool_allocator)
* the ability to play nicely with the standard containers

In short, I think standard allocators are a squeaky wheel, but in most
cases it better to grease that wheel than reinvent it.