Re: [boost] Re: Boost memory management guidelines

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

On Tuesday, Sep 2, 2003, at 12:51 America/Denver, David Abrahams wrote:

> Gregory Colvin <gregory.colvin_at_[hidden]> writes:
>
>> On Tuesday, Sep 2, 2003, at 11:22 America/Denver, David Abrahams 
>> wrote:
>>> Gregory Colvin <gregory.colvin_at_[hidden]> writes:
>>>
>>>> So you would rather use this than use construct?
>>>>
>>>>    template <typename T> T* addressof(T& v)
>>>>    {
>>>>      return reinterpret_cast<T*>(
>>>>           &const_cast<char&>(reinterpret_cast<const volatile char
>>>>           &>(v)));
>>>>    }
>>>
>>> As long as it's packaged away and I don't have to look at the
>>> implementation.  A customization point like an allocator should not 
>>> be
>>> required to supply boilerplate that's always going to be the same.
>>
>> You are assuming that there was no good reason to allow an allocator
>> to hook construct and destroy, for instance to do some bookkeeping.
>
> The fact that nobody's required to use construct and/or destroy is
> testament to that.

Thanks to the weasel-wording nobody's required to use much of
anything besides allocate, deallocate, and rebind.  That doesn't
mean there was no point to all the rest in the original design.

>>> When I need to find out what I need to implement in order to
>>> customize allocation, I don't want to have to read through
>>> something which is 50% irrelevant to the task, as the allocator
>>> requirements are.
>>
>> Which is why I'm now suggesting that Boost UserAllocator is a better
>> default.
>>
>> But in some cases, like the shared_ptr feature request that got me
>> thinking on this, what you want is just to have objects allocate
>> their internals using the same allocator as the container they
>> are being placed in, in which case you don't need to implement an
>> allocator, just call get_allocator().
>
> Is it enough for all of Boost?

It's probably overkill for some things.

>   If so, great!  If not, we still need
> to think about what a more-sophisticated interface looks like.

Only if UserAllocator is inadequate?

> Also, if shared_ptr only needs to allocate at construction time (I'm
> not sure of this) we can avoid storing the allocator at all.

Then how to deallocate?

>> I'm reeling from the implication that the following is undefined
>> behavior for non-POD T:
>>
>> 	T* p = (T*)malloc(sizeof T);
>>
>> Are you sure?
>
> Nope.  3.8/5 shows that I'm wrong.

That's a relief.

>  It still doesn't make any sense to
> return a T* from allocate since normally with a non-singular T* p,
> either p == 0 or *p refers to a constructed T.

The idea was that Allocator<T>::pointer might be a proxy type
that cannot be converted to void* and back, so allocate() must
return and construct() must take an Allocator<T>::pointer rather
than a void*.