On Fri, Feb 06, 2004 at 07:00:49PM -0500, David Abrahams wrote:
The example below shows a technique for perfect forwarding that seems to work with GCC 3.3.1. rvalues are always moved automatically, and lvalues are copied.
I had to Google for "perfect forwarding" to discover http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm (which I'd read before but forgotten about). It is unclear to me if/how your code solves the "perfect forwarding" problem. Instead it appears to show a way to make a particular type "movable". Have I misunderstood? (How) does your generalize to a way to write forwarding functions? 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?
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? In test10, what do you 'want' to happen here: sink2( <a temporary object, that is, an rvalue> ); ? Overall it looks clever, but I don't yet understand exactly what it solves or the details of the 12.2/1 thing. -- -Brian McNamara (lorgon@cc.gatech.edu)