[boost] Re: Boost memory management guidelines

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-02 06:42:28

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

> On Monday, Sep 1, 2003, at 14:48 America/Denver, David Abrahams wrote:
>> Gregory Colvin <gregory.colvin_at_[hidden]> writes:
>>
>>>>> Conforming containers had better use them.
>>>>
>>>> I'm sorry, but I think that's flat wrong.  What do you suppose that
>>>> entry in column 2 of the allocator requirements table (20.1.5) means,
>>>> after all?
>>>
>>> It means any value returned by construct, destroy, or deallocate goes
>>> unused.
>>>
>>>>> And once you are down in the coal mine customizing what a pointer
>>>>> is, I'm not sure you won't need to customize how to construct and
>>>>> destroy.
>>>>
>>>> The class getting constructed/destroyed has full control over that or
>>>> the language is utterly bustificated.
>>>
>>> Yes, but the allocator may want to do something else as well, and
>>> construct and destroy serve as hooks for whatever that may be.
>>
>> Regardless, there is absolutely _nothing_ in the standard AFAICT which
>> indicates the containers must use the allocator's construct and
>> destroy, and several implementations in fact do not.
>
> Well then, I consider the standard broken in that regard.  But we are
> off the topic that started this thread.
>
> Apropos of which, I now think that the Boost UserAllocator requirements
> should be the default for components that parameterize how they use
> memory, with the Standard Allocator requirements being used only for
> components that need what they offer: a potentially very efficient way
> to allocate large numbers of small objects of known type, and/or a
> way to access storage via proxied pointers.

I think part of my point was that *nobody* needs what they offer, if
you include construct/destroy.  In fact, construct requires undefined
behavior for non-POD T because you can't copy its T* argument which
points into raw storage.

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.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com