Gregory Colvin <[EMAIL PROTECTED]> 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?
It means any value returned by construct, destroy, or deallocate goes unused.
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.
Yes, but the allocator may want to do something else as well, and construct and destroy serve as hooks for whatever that may be.
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.
Agreed.
^^^^^^^^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.
Silly me for not compiling my email.
Just a small example of why I'm saying it's a harder interface.
Very small.
Allocator has strange requirements, like "p shall not be null".
Another performance optimization. In most cases there is no way that p could be null in the first place, so why waste time checking?
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.
Agreed. The Boost UserAllocator is easier to implement and to use.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
