| Message ID | 20150310174355.GA13455@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 03/10/2015 11:43 AM, Jonathan Wakely wrote: > > +<h3>Return by converting move constructor</h3> > + > +<p>GCC 5 implements > +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579">DR 1579</a> > +which means that in a function like:</p> > + > +<pre><code> > + X > + foo() > + { > + Y y; > + return y; > + } > +</code></pre> > + > +<p>GCC will first attempt to construct the return value as if <code>y</code> > +were an rvalue, and if that fails then it will try again for an lvalue > +(all C++11 compilers already do this when returning a variable of the > +same type as the function returns, but now they are required to do it > +when the types are not the same). > +This will change the constructor that gets called in some cases, > +for example it might now call <code>X(Y&&)</code> instead of > +<code>X(const Y&)</code>. > +</p> > +<p> > +In most cases the only observable difference will be code that runs faster > +(by moving instead of copying) but if it causes a problem the new behavior > +can be prevented by ensuring the compiler treats <code>y</code> as an lvalue, > +using <code>return X(y);</code> or > +<code>return static_cast<Y&>(y);</code>. > +</p> > + Errrmmmm. If GCC 5 implements (present tense) this new feature, why is the description written mostly in the future tense? :-( -Sandra the grammar geek
On 10/03/15 12:10 -0600, Sandra Loosemore wrote: >Errrmmmm. If GCC 5 implements (present tense) this new feature, why >is the description written mostly in the future tense? :-( When compiling such a function, GCC will do as described. I'm happy to change it though, how's the attached revision? (I also changed "as if y were an rvalue" to "as though y were an rvalue" because the repetition of "if" that follows seems clunky now I read it again.)
Index: porting_to.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/porting_to.html,v retrieving revision 1.5 diff -u -r1.5 porting_to.html --- porting_to.html 18 Feb 2015 13:41:12 -0000 1.5 +++ porting_to.html 10 Mar 2015 17:37:15 -0000 @@ -385,6 +385,38 @@ It is recommended to use <code>true</code>, resp. <code>false</code> keywords in such cases. +<h3>Return by converting move constructor</h3> + +<p>GCC 5 implements +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579">DR 1579</a> +which means that in a function like:</p> + +<pre><code> + X + foo() + { + Y y; + return y; + } +</code></pre> + +<p>GCC will first attempt to construct the return value as if <code>y</code> +were an rvalue, and if that fails then it will try again for an lvalue +(all C++11 compilers already do this when returning a variable of the +same type as the function returns, but now they are required to do it +when the types are not the same). +This will change the constructor that gets called in some cases, +for example it might now call <code>X(Y&&)</code> instead of +<code>X(const Y&)</code>. +</p> +<p> +In most cases the only observable difference will be code that runs faster +(by moving instead of copying) but if it causes a problem the new behavior +can be prevented by ensuring the compiler treats <code>y</code> as an lvalue, +using <code>return X(y);</code> or +<code>return static_cast<Y&>(y);</code>. +</p> + <h3>Links</h3> <p>