This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/37206] New: [c++0x] Spurious copy/move requirement for initialization of rvalue reference variable from rvalue initializer.
- From: "gcc-bugzilla at contacts dot eelis dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 22 Aug 2008 21:57:53 -0000
- Subject: [Bug c++/37206] New: [c++0x] Spurious copy/move requirement for initialization of rvalue reference variable from rvalue initializer.
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
Consider:
struct nocopy { private: nocopy(nocopy const&); };
nocopy && f();
nocopy && r = f();
On the last line, g++ 4.4 (with -std=c++0x) complains:
error: "nocopy::nocopy(const nocopy&)" is private in this context
Thus, it seems g++ wants to create a temporary. While there
are many similar situations that do indeed call for the creation
of a temporary, I think there is no such requirement here.
With regard to initialization of a reference of type "cv1 T1" by an
expression of "cv2 T2", 8.5.3p5 item 2, subitem 1 in n2691 (the
latest C++0x draft) states:
If the initializer expression is an rvalue, with T2 a class type,
and "cv1 T1" is reference-compatible with "cv2 T2," the
reference is bound to the object represented by the rvalue
or to a sub-object within that object.
This item applies because the expression f() is an rvalue (by 5p6),
nocopy is a class type, and nocopy is reference compatible with
itself (by 8.5.3p4). Hence, there is no call for a temporary, and the
code should be accepted.
At least, that's my humble interpretation. Apologies if I overlooked
something or misunderstood the wording in the draft.
--
Summary: [c++0x] Spurious copy/move requirement for
initialization of rvalue reference variable from rvalue
initializer.
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37206