On Monday, Sep 1, 2003, at 14:48 America/Denver, David Abrahams wrote:
Gregory Colvin <[EMAIL PROTECTED]> writes:
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.
Regardless, there is absolutely _nothing_ in the standard AFAICT which
indicates the containers must use the allocator's construct and
destroy, and several implementations in fact do not.
Well then, I consider the standard broken in that regard. But we are
off the topic that started this thread.
Apropos of which, I now think that the Boost UserAllocator requirements
should be the default for components that parameterize how they use
memory, with the Standard Allocator requirements being used only for
components that need what they offer: a potentially very efficient way
to allocate large numbers of small objects of known type, and/or a
way to access storage via proxied pointers.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
