On Tuesday, Sep 2, 2003, at 12:51 America/Denver, David Abrahams wrote:
Gregory Colvin <[EMAIL PROTECTED]> writes:
On Tuesday, Sep 2, 2003, at 11:22 America/Denver, David Abrahams wrote:Gregory Colvin <[EMAIL PROTECTED]> 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.
Thanks to the weasel-wording nobody's required to use much of anything besides allocate, deallocate, and rebind. That doesn't mean there was no point to all the rest in the original design.
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?
It's probably overkill for some things.
If so, great! If not, we still need to think about what a more-sophisticated interface looks like.
Only if UserAllocator is inadequate?
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.
Then how to deallocate?
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.
That's a relief.
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.
The idea was that Allocator<T>::pointer might be a proxy type that cannot be converted to void* and back, so allocate() must return and construct() must take an Allocator<T>::pointer rather than a void*.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
