[boost] Re: Boost memory management guidelines

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-31 14:13:57

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

>>> But indeed allocate/construct/deallocate/destroy is more work than
>>                       ^^^^^^^^^            ^^^^^^^
>> Oyeah.  These two absolutely don't belong in allocator, period.  Do
>> any implementations even use them?  Allocators exist to provide a
>> point of customization for users, but you cannot/should not customize
>> these.
>
> 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?

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

>> Using allocator is even more work than allocating raw memory with
>> malloc and doing placement new and explicit destruction, then freeing
>> the raw memory.  That's my biggest complaint.
>
> It's new/delete
>
>    T* p = new T();
>    ...
>    delete p;
>
> versus malloc/free
>
>    T* p = (T*)malloc(sizeof T);

When you need

     malloc(sizeof(T) + N)

Allocators get a lot harder to use.

>    new(p) T();
>    ...
>    p->~T();
>    free(p);
>
> versus Boost UserAllocator
>
>    T* p = (T*)user_allocator::malloc(sizeof T);
>    new(p) T();
>    ...
>    p->~T();
>    user_allocator::free(p);
>
> versus standard Allocator
>
>    Allocator::pointer p = allocator.allocate(sizeof T);
>    allocator.construct(p,T());
>    ...
>    allocator.destroy(p);
>    allocator.deallocate(sizeof T);
                          ^^^^^^^^

Oops! There's a pointer missing here.  Just a small example of why I'm
saying it's a harder interface.  Allocator has strange requirements,
like "p shall not be null".  If I need to build a custom one I have to
navigate rebind and the implications of allocator inequality for which
the standard provides little guidance.

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