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. In fact, construct requires undefined
behavior for non-POD T because you can't copy its T* argument which
points into raw storage.
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.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
