On Tuesday, Sep 2, 2003, at 05:42 America/Denver, David Abrahams wrote:
Gregory Colvin <[EMAIL PROTECTED]> writes:
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.
I think part of my point was that *nobody* needs what they offer, if
you include construct/destroy.
Or rather that some implementations have failed to use what they
offer, and our standard unfortunately doesn't insist that they do.
Another reason construct is needed is that Allocator::pointer might
be a proxy, with operator* and operator-> but not necessarily a
conversion to void* or even T*.
In fact, construct requires undefined
behavior for non-POD T because you can't copy its T* argument which
points into raw storage.
I don't understand what you mean by this. Are you claiming that
it is undefined to copy just a pointer to raw storage? If so,
then how is placement new not undefined? The standard says:
a.construct(p,t)
Effect: new((void*)p) T(t)
I think I would rather see a MPL lambda expression or metafunction
class interface for allocator type parameters. It makes little sense
for the allocator's user to be choosing its value_type.
Something like:
some_allocator<_1>
or
struct select_allocator
{
template <class T>
struct apply
{
typedef some_allocator<T> type;
};
};
with some_allocator's interface being like what's required for
std::allocator but not including misplaced interface bits such as
address/construct/destroy, and possibly max_size -- these can be added
by a std::allocator facade wrapper if neccessary.
I'm not sure we need a simple version and a complicated version.
I'm not clear how you intend the above to be used, or what you
intend it to be a replacement for.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
