Brian McNamara <lorgon@cc.gatech.edu> writes:
It seems you have a clever way to effectively "detect rvalue-ness"; the copy-constructor and the "pseudo-copy-constructor" (the thing with the enable_if) only swallow lvalues, whereas rvalues find a more attractive construction path via "ref". Is that a correct summary?
I think so.
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. -- Dave Abrahams Boost Consulting www.boost-consulting.com