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
> 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,
> 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
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();
> versus Boost UserAllocator
> T* p = (T*)user_allocator::malloc(sizeof T);
> new(p) T();
> versus standard Allocator
> Allocator::pointer p = allocator.allocate(sizeof T);
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk