Topic: Defect Report: Overload resolution implied without specifying how the set of candidate functions is to be formed


Author: "Andrei Iltchenko" <iltchenko@yahoo.com>
Date: 17 Jun 01 21:48:39 GMT
Raw View
 [Moderator's note: this defect report has been
 forwarded to the C++ committee. -moderator(fjh).]

Section: 8.5.3 - References [dcl.init.ref]
Submitter: Andrei Iltchenko (iltchenko@yahoo.com)

There is a place in the Standard where overload resolution is implied but
the way that a set of candidate functions is to be formed is omitted. See
below.

According to the Standard, when initializing a reference to a non-volatile
const class type (cv1 T1) with an rvalue expression (cv2 T2) where cv1 T1 is
reference compatible with cv2 T2, the implementation shall proceed in one of
the following ways (except when initializing the implicit object parameter
of a copy constructor) 8.5.3 [dcl.init.ref] paragraph 5 bullet 2:

- The reference is bound to the object represented by the rvalue (see 3.10)
or to a sub-object within that object.
- A temporary of type "cv1 T2" [sic] is created, and a constructor is called
to copy the entire rvalue object into the temporary...

While the first case is quite obvious, the second one is a bit unclear as it
says "a constructor is called to copy the entire rvalue object into the
temporary" without specifying how the temporary is created -- by
direct-initialization or by copy-initialization 8.5 [dcl.init]? As stated in
DR 152, this
can make a difference when the copy constructor is declared as explicit. How
should the set of candidate functions be formed? The most appropriate guess
is that it shall proceed as per 13.3.1.3 [over.match.ctor].


Another detail worth of note is that in the draft version of the Standard as
of 2 December 1996 the second bullet of 8.5.3 [dcl.init.ref] paragraph 5
read:

 - A temporary of type "cv1 T2" [sic] is created, and a copy constructor is
called to copy the entire rvalue object into the temporary...

J. Stephen Adamczyk replied that the reason for changing "a copy
constructor" to "a constructor" was to allow for member template converting
constructors.

However, the new wording is somewhat in conflict with the footnote #93 on
page 148 that says that when initializing the implicit object parameter of a
copy constructor an implementation must eventually choose the first
alternative (binding without copying) to avoid infinite recursion. This
seems to suggest that a copy constructor is always used for initializing the
temporary of type "cv1 T2".

Furthermore, now that the set of candidate functions is not limited to only
the copy constructors of T2, there might be some unpleasant consequences.
Consider a rather contrived sample below:
int   * pi = ::new(std::nothrow) int;
const std::auto_ptr<int>   & ri = std::auto_ptr<int>(pi);

In this example the initialization of the temporary of type 'const
std::auto_ptr<int>' (to which 'ri' is meant to be subsequently bound)
doesn't fail, as it would had the approach with copy constructors been
retained, instead, a yet another temporary gets created as the well-known
sequence:
std::auto_ptr<int>::operator std::auto_ptr_ref<int>()
std::auto_ptr<int>(std::auto_ptr_ref<int>)
is called (assuming, of course, that the set of candidate functions is
formed as per 13.3.1.3 [over.match.ctor]). The second temporary is transient
and gets destroyed at the end of the initialization. I doubt that this is
the way that the committee wanted this kind of reference binding to go.

Besides, even if the approach restricting the set of candidates to copy
constructors is restored, it is still not clear how the initialization of
the temporary (to which the reference is intended to be bound) is to be
performed -- using direct-initialization or copy-initialization 8.5
[dcl.init].

Another place in the Standard that would benefit from a similar
clarification is the creation of an exception object, which is delineated in
15.1 [except.throw].


Regards,

Andrei Iltchenko.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]