[PATCH] rvalue reference implementation for C++0x

Jason Merrill jason@redhat.com
Fri Mar 9 22:16:00 GMT 2007

Mostly looks good.  A few comments:

Need a space before the ( in many of the uses of TYPE_REF_IS_RVALUE and 
some other places.

I'd rather not expose the concept of an rvalue reference to the back 
end, its semantics should be encapsulated by the front end.  I think the 
right answer is to have a wrapper for build_reference_type_* in the 
front end to handle the extra semantics.

I'm not sure what the best coding strategy is for this.  One option 
would be to establish a convention of putting the rvalue ref after the 
non-rvalue ref in the TYPE_NEXT_REF_TO chain, or in some other field if 
there are others free, so that the C++ front end function can call the 
back end function and then use the result to look up the rvalue version.

Please quote the reference collapsing rules where you implement them in 
grokdeclarator and tsubst.

I'd change "valuedness" to "rvalueness" for clarity, as "valuedness" 
could mean "the state of having a value".

The test in compare_ics seems to check for cases where one conversion 
has matching rvalueness and the other doesn't, but that isn't all the 
rule in the working paper talks about: it also requires that for one ICS 
to be better than the other, the two references must differ in 
rvalueness, one converting to lvalue ref and the other to rvalue ref or 
vice versa.

In lvalue_p_1, I'd clarify the INDIRECT_REF comment by noting that the 
INDIRECT_REFs are just internal compiler representation, not part of the 
language, so we have to look through them.

Please send mail to cxx-abi-dev@codesourcery.com about allocating a new 
type encoding for rvalue references.  Since this is part of C++0x, it 
shouldn't be mangled using a vendor extension, it should be added to the 
standard ABI.  Also, I'd expect it to be used instead of the "R" for an 
lvalue reference, not in addition.

About the deduce_ref stuff: why not just add the REFERENCE_TYPE to arg 
in type_unification_real rather than add another argument to unify?


More information about the Gcc-patches mailing list