|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-09-02 12:22:24
Gregory Colvin <gregory.colvin_at_[hidden]> writes:
> On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams wrote:
>
>> Gregory Colvin <gregory.colvin_at_[hidden]> writes:
>>
>>>> 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.
>>
>> It's not unfortunate if it adds nothing, which is what I believe.
>>
>>> 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*.
>>
>> Doesn't matter; you can always get the address of an object. See
>> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#390
>
> 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.
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.
>>>> 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?
>>
>> Unless the pointer has the right type, yes.
>
> In which case the A::pointer return from A::allocate() is already
> undefined behavior?
Wow. Yes, IIUC. DR, I guess.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk