Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at