Re: [boost] Re: Copy Constructible Concept

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-11-15 15:03:03

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)));
  }

Note: this relates directly to library issue 350, which will need to
be reexamined if the CopyConstructible requirements change.

Proposed resolution:

Remove the last two rows of Table 30, eliminating the requirements
that &t and &u return the address of t and u, respectively.
--------------------------------------------------------------------------------

        Doug