Re: [boost] Re: Copy Constructible Concept

From: David Abrahams (dave_at_[hidden])
Date: 2002-11-15 15:26:59

Douglas Gregor <gregod_at_[hidden]> writes:

> On Friday 15 November 2002 02:42 pm, Gennaro Prota wrote:
>> On Fri, 15 Nov 2002 13:24:41 -0500, Douglas Gregor <gregod_at_[hidden]>
>>
>> wrote:
>> >Most likely, those present either didn't think it was a problem or didn't
>> > feel strongly enough about the situation to speak up. There really aren't
>> > all that many good uses for overloading operator&, and it can be a bit
>> > dangerous, so I would expect some resistence in getting it removed from
>> > the CopyConstructible requirements. Come to think of it, if not for
>> > Lambda's overloading of operator&, I wouldn't really care about the issue
>> > :)
>>
>> Hmmm... if you proposed a resolution, could you please publish/post
>> the text of your report?
>>
>> Genny.
>
> Strange that it wasn't in the Post-Santa Cruz mailing. Here's the text:
>
> --------------------------------------------------------------------------------
> Defect report: CopyConstructible requirements too strict
> Section: 20.1.3 [lib.copyconstructible]
>
> The CopyConstructible requirements in Table 30 state that for an
> object t of type T (where T is CopyConstructible), the expression &t
> returns the address of t (with type T*). This requirement is overly
> strict, in that it disallows types that overload operator& to not
> return a value of type T*. This occurs, for instance, in the <a
> href="http://www.boost.org/lib/lambda">Boost.Lambda</a> library
> function objects overload operator& to return the address of the
> result of calling a function object. Example:
>
>   std::vector<int> u, v;
>   int x;
>   // ...
>   std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x);
>
> _1 * x returns an unnamed function object with operator& overloaded,
> therefore rendering the std::transform call ill-formed. However, most
> standard library implementations will compile this code properly, and
> the viability of such binder libraries is severely hindered by the
> unnecessary restriction in the CopyConstructible requirements.
>
> For reference, the address of an object can be retrieved without using
> the address-of operator with the following function template:
>
>   template <typename T> T* addressof(T& v)
>   {
>     return reinterpret_cast<T*>(
>          &const_cast<char&>(reinterpret_cast<const volatile char &>(v)));
>   }

Ouch! Did we really write that in the DR? Didn't we just have a long
argument in this forum about how the results of reinterpret_cast are
not portable?!

That should be:

     ...

Umm, actually I don't see a way to write that in a portable
manner. I'm afraid we just made another DR mistake. I don't think the
CopyConstructible requirements were to strict before the DR was
issued. I hope there's a way to take it back. Matt?

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution