[boost] Re: Boost memory management guidelines

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-02 13:51:35

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.

>> 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?  If so, great!  If not, we still need
to think about what a more-sophisticated interface looks like.

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.

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

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