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
> 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
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
>>> 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