Boost logo

Boost :

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-09-02 09:21:58

On Tuesday, Sep 2, 2003, at 05:42 America/Denver, David Abrahams wrote:
> Gregory Colvin <gregory.colvin_at_[hidden]> writes:
>> On Monday, Sep 1, 2003, at 14:48 America/Denver, David Abrahams wrote:
>>> Gregory Colvin <gregory.colvin_at_[hidden]> 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:

   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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at