Re: [boost] Re: Boost memory management guidelines

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

On Tuesday, Sep 2, 2003, at 05:42 America/Denver, David Abrahams wrote:
> 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.

Or rather that some implementations have failed to use what they
offer, and our standard unfortunately doesn't insist that they do.

Another reason construct is needed is that Allocator::pointer might
be a proxy, with operator* and operator-> but not necessarily a
conversion to void* or even T*.

>   In fact, construct requires undefined
> behavior for non-POD T because you can't copy its T* argument which
> points into raw storage.

I don't understand what you mean by this.  Are you claiming that
it is undefined to copy just a pointer to raw storage?  If so,
then how is placement new not undefined?  The standard says:

   a.construct(p,t)
   Effect: new((void*)p) T(t)

> 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.