Re: [boost] Boost memory management guidelines

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-08-30 11:18:23

On Saturday, Aug 30, 2003, at 07:31 America/Denver, Peter Dimov wrote:
> Gregory Colvin wrote:
>> 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.
>
> They work, but they arguably aren't well designed.

They could be better, as could lots of things in the standard.  For
instance, I objected to std::string from the start, and came to loath
it over the years as it accreted more and more cruft.  But it does
the job, so I use it and recommend that others do, rather than go
off and design my own.

>  Containers manage memory
> in different ways.
>
> vector<T> allocates, reallocates, and deallocates contiguous blocks of 
> T
> elements, and it can put a "how much did I just allocate" feature and 
> a "how
> big is this allocation" feature to good use.
>
> Node-based containers allocate single nodes, but not of value_type.
>
> Deque allocates fixed size pages (and some additional housekeeping 
> data).
>
> I'm not sure that lumping these together in a single Allocator concept 
> has
> any benefits.

I'm not either, but what's done is done.  And given how much is in
there, I think in most cases where one needs an interface to say
"please tell me how to allocate and free memory" that a subset of
the Allocator interface will do the job.

> The stateful allocator problem is a thorny issue too, since to allow
> stateful allocators, one needs to specify whether the stored allocator 
> is
> part of the logical state of the object. IE
>
> vector<T, A> v1(a1);
> vector<T, A> v2(a2);
>
> v1 = v2; // which allocator does v1 hold now?

I think the standard doesn't say.  Unfortunately, as it seems like
one of those questions for which having some answer matters more
that which answer you have.  But I agree with Howard's analysis,
and hope that in the standard we can remove the weasel wording and
nail down these and other such loose ends.  For instance, should
the following be allowed?

   vector<T, A> v(a);
   vector<T, B> w(b);
   a = b;

> Extending this already overstretched concept to function<> is a bad 
> idea
> IMHO.

I don't know enough about function<> to have an opinion, but it may
well fall under the "clear advantage" escape clause.

> function<> has its own memory management pattern that does not even
> resemble a container. In particular
>
> function<void(), A> f(a);
>
> is not required since f never allocates except when passed an object.
>
> function<void(), A> f(x, a);
>
> can be made to work without the A template parameter since the 
> constructor
> is already a template, and x and a can be treated as a whole:
>
> function<void()> f(x, a); // allocate pair<X, A> with a, copy x and a 
> into
> it.

So the questions are:  Is this worth doing?  And if so, should A meet
the standard Allocator requirements, or have some other interface?