On Sun, Feb 08, 2004 at 03:07:05PM -0500, David Abrahams wrote:
Brian McNamara <lorgon@cc.gatech.edu> writes:
On Sun, Feb 08, 2004 at 11:39:51AM -0500, David Abrahams wrote:
Brian McNamara <lorgon@cc.gatech.edu> writes:
David Abrahams writes:
12.2/1 says that the act of binding an rvalue to a (const) reference creates a temporary (which may be elided). The creation of the temporary requires the existence of a copy ctor with a const& argument. As far as I know, that rule serves no useful purpose, but I may have missed something.
I am not sure what portion of the rule you don't like. Is it the fact that they point to a particular copy constructor (the const& one), rather than just any available/visible/something copy constructor?
No, it's the fact that any additional temporary at all (and thus, a copy ctor) is needed.
In test10, what do you 'want' to happen here: sink2( <a temporary object, that is, an rvalue> );
It should bind a const reference to the temporary without complaining that the temporary can't be copied.
I see. What about
const X& x = source(); // 12.2/5
? Or something.
That's exactly the case I'm talking about.
I am trying to find the 'hard' cases where the compiler might not be able to easily make the temporary have the right 'lifetime', and thus require an extra copy.
I don't see any problem here. There's no problem getting the rvalue out of source(), or sink(source()) would fail. Furthermore, no
I think we're on the same page, but to clarify--this case const X& x = source(); // 12.2/5 seems harder than this one sink(source()); to me, since in the former, the "temporary" object must have a lifetime that outlasts the full expression that created it.
compiler I've ever seen will actually make the allowed temporary in that case.
But if that's true, then I agree with you that I don't see "the point of the rule", so go lobby to change it and be the hero of many. :) -- -Brian McNamara (lorgon@cc.gatech.edu)