This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] rvalue reference implementation for C++0x
On 4/26/07, Russell Yanofsky <russ@yanofsky.org> wrote:
On Thu, 2007-04-26 at 18:20 -0400, Jason Merrill wrote:
> Russell Yanofsky wrote:
>
> > struct A {};
> >
> > struct B : A
> > {
> > B(int);
> > B(B &);
> > B(A);
> > };
> >
> > Since B doesn't have a const copy constructor, initializing the variable
> > directly from the temporary is impossible. But the class A has an
> > implicit const copy constructor which is allowed to bind to temporary
> > instances of B under C++0x.
>
> Yes, but you can't use a constructor for A to intialize an object of
> type B. We should only be considering the B constructors.
The code above declares a "B(A)" constructor to make it explicitly
possible to initialize a instance of type B from an instance of type A.
The presence of the "B(A)" constructor is what makes the whole thing
work. I also thought these two test cases revealed bugs when I first saw
them, but that was before noticing the "B(A)" constructor.
Looking more closely at this, I think Jason is right... the B(A)
allows us to build a B, but we still need a copy constructor to make a
copy of the B before binding the reference. Now, the compiler is
permitted to elide the actual copy construction... but the copy
constructor needs to be there even if the copy construction will be
elided. I had thought that the rvalue references proposal change this,
but it did not. This paragraph from N2118 points out explicitly that
out explicitly:
-16- When the criteria for elision of a copy operation are met and the
object to be copied is designated by an lvalue, overload resolution to
select the constructor for the copy is first performed as if the
object were designated by an rvalue. If overload resolution fails, or
if the type of the first parameter of the selected constructor is not
an rvalue-reference to the object's type (possibly cv-qualified),
overload resolution is performed again, considering the object as an
lvalue. [Note: This two-stage overload resolution must be performed
regardless of whether copy elision will occur. It determines the
constructor to be called if elision is not performed, and the selected
constructor must be accessible even if the call is elided. —end note]
So, it looks to me like there's a little bit of work left to do on the
rvalue references patch before it's ready for prime time, but it's
really close...
- Doug