Re: [boost] Re: Boost memory management guidelines

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-09-02 11:31:09

On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams wrote:

> Gregory Colvin <gregory.colvin_at_[hidden]> writes:
> ...
>> Dave:
>>> I think I would rather see a MPL lambda expression or metafunction
>>> class interface for allocator type parameters.  It makes little sense
>>> for the allocator's user to be choosing its value_type.
>>>
>>> Something like:
>>>
>>>   some_allocator<_1>
>>>
>>> or
>>>
>>>   struct select_allocator
>>>   {
>>>       template <class T>
>>>       struct apply
>>>       {
>>>           typedef some_allocator<T> type;
>>>       };
>>>   };
>>>
>>> with some_allocator's interface being like what's required for
>>> std::allocator but not including misplaced interface bits such as
>>> address/construct/destroy, and possibly max_size -- these can be 
>>> added
>>> by a std::allocator facade wrapper if neccessary.
>>>
>>> I'm not sure we need a simple version and a complicated version.
>>
>> I'm not clear how you intend the above to be used, or what you
>> intend it to be a replacement for.
>
> I intend it to be the sort of type parameter that gets passed to our
> objects which need custom allocation in place of a standard allocator.
> It's ridiculous, IMO, to pass allocator<T> to a node-based container
> which is *never* going to allocate a T object.

But given rebind() it doesn't really matter.  We could just as
well have specified that all containers take allocator<void>
arguments.

>   The container itself
> should decide which type the allocator template gets instantiated on,
> via:
>
>     mpl::apply<mpl::lambda<S>, Node>::type
>
>      [
>        this is approximately the same as:
>
>          S::template apply<U>::type == some_allocator<U>
>
>        except that it works when S is the lambda expression
>        some_allocator<_1> as well as when it's the select_allocator
>        metafunction class below it.
>      ]
>

Sorry, but I'm still not following this, but that may be
because I don't know much MPL, so I can only guess at what
you are up to.  I probably need a detailed example of how to
write and use one of these thingys to make any sense of your
proposal.

Does your proposal support stateful allocators?

> What the rebind requirement in the allocator means for pool
> allocation, for example, is that a pool_allocator<T> object must
> either be stateless (in which case allocator inequality is
> meaningless)

Yes, all stateless allocators compare equal, and stateless
allocators are the easiest kind to make compare equal, as
the standard currently requires allocators to do.

> or effectively be able to allocate blocks of *any* size
> and alignment, rather than just as appropriate for T.

Yes, because node-based containers need to allocate nodes,
perhaps of various kinds, but they don't expose their
node types in their interface.  So you have to pass in
something, and we went with T rather than void or whatever.

It might have been better to have different allocator
interfaces for array-based versus node-based containers,
since array-based containers have no need of rebind(), and
node-based containers have no need of allocator<T>.

>   It's a conceptual mess.

Alex didn't have MPL when he invented allocators.  So they are
messier than they need to be, but I still say they are not so
bad as you claim, and that it would be easier for the next
standard to repair them than to replace them.