You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
C f()
{
C c = C() /* NRVO variable */;
return C(static_cast<C &&>(c));
}
If I substitute this directly in the code however, the compiler can no longer apply NRVO and instead calls the move constructor on c. See https://godbolt.org/z/qecYW1e9e. When returning c directly, there is no move constructor and only one destructor called.
Note however that if c is a parameter then the move construction is necessary, so this seems to be a correct translation in that case, e.g.
C f(C c) {
return c; // return C(static_cast<C &&>(c));
}
The text was updated successfully, but these errors were encountered:
NRVO is tricky. It is an optimization performed by the compiler in the back end. C++ Insights looks at the front end. The thing that plays the major role here is guaranteed copy elison.
Notice that it says nrvo_candidate at this point. The compiler may decide differently. However, I will use that information and keep the variable in that case. A fix is on its way.
I wonder if it would make sense to add another comment to the return statement to emphasize that NRVO is happening (in case the variable declaration is far away)?
When given a function invoking NRVO, for example:
The insight returns
If I substitute this directly in the code however, the compiler can no longer apply NRVO and instead calls the move constructor on c. See https://godbolt.org/z/qecYW1e9e. When returning c directly, there is no move constructor and only one destructor called.
Note however that if c is a parameter then the move construction is necessary, so this seems to be a correct translation in that case, e.g.
The text was updated successfully, but these errors were encountered: