[Audacity-devel] Use of std::move in return statments

Discussion:

David Bailes

2016-09-15 10:44:37 UTC

http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-move

Based on these guidelines, std::move does not need to be used for local
variables in return statements, but it's used several times in the Audacity
code.

David.

Paul Licameli

2016-09-15 11:43:04 UTC

Permalink

Aha, that document is edited by Stroustrup himself, and should repay study.

I will remove the unnecessary moves.

PRL

Post by David Bailes
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-move
Based on these guidelines, std::move does not need to be used for local
variables in return statements, but it's used several times in the Audacity
code.
David.
------------------------------------------------------------
------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Paul Licameli

2016-09-17 15:10:22 UTC

Permalink

I removed all the unnecessary moves in returns that I could.

But there were places where unique_ptr<Base> needed to be returned (such as
when Base is Track), but the expression returned had type
unique_ptr<Derived> (such as WaveTrack). Then I could not remove
std::move, at least with the Mac compiler.

I am not sure whether the standard says this should work, but standard
compliance is lacking on this compiler, or whether there is something in
the standard justifiying this. Whatever the case, I could not remove all
std::move in return statements.

PRL

Post by Paul Licameli
Aha, that document is edited by Stroustrup himself, and should repay study.
I will remove the unnecessary moves.
PRL

David Bailes

2016-09-17 16:10:31 UTC

Permalink

Post by Paul Licameli
I removed all the unnecessary moves in returns that I could.
But there were places where unique_ptr<Base> needed to be returned (such
as when Base is Track), but the expression returned had type
unique_ptr<Derived> (such as WaveTrack). Then I could not remove
std::move, at least with the Mac compiler.
I am not sure whether the standard says this should work, but standard
compliance is lacking on this compiler, or whether there is something in
the standard justifiying this. Whatever the case, I could not remove all
std::move in return statements.

thanks for the update. Unfortunately it looks like the standard says that
std::move is needed in the return statement if the types aren't the same.
Maybe they'll change the standard one day to cover the
unique_ptr<Base/Derived> case.

See for example:
http://en.cppreference.com/w/cpp/language/copy_elision

Here's the relevant section:

- If a function returns a class type by value, and the return statement
<http://en.cppreference.com/w/cpp/language/return>'s expression is the
name of a non-volatile object with automatic storage duration, which isn't
the function parameter, or a catch clause parameter, and which has the same
type (ignoring top-level cv-qualification
<http://en.cppreference.com/w/cpp/language/cv>) as the return type of
the function, then copy/move is omitted. When that local object is
constructed, it is constructed directly in the storage where the function's
return value would otherwise be moved or copied to. This variant of copy
elision is known as NRVO, "named return value optimization".

David.

Post by Paul Licameli
PRL

Post by Paul Licameli
Aha, that document is edited by Stroustrup himself, and should repay study.
I will remove the unnecessary moves.
PRL

------------------------------------------------------------
------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Paul Licameli

2016-09-17 16:59:47 UTC

Permalink

Post by David Bailes

thanks for the update. Unfortunately it looks like the standard says that
std::move is needed in the return statement if the types aren't the same.
Maybe they'll change the standard one day to cover the
unique_ptr<Base/Derived> case.
http://en.cppreference.com/w/cpp/language/copy_elision
- If a function returns a class type by value, and the return statement
<http://en.cppreference.com/w/cpp/language/return>'s expression is the
name of a non-volatile object with automatic storage duration, which isn't
the function parameter, or a catch clause parameter, and which has the same
type (ignoring top-level cv-qualification
<http://en.cppreference.com/w/cpp/language/cv>) as the return type of
the function, then copy/move is omitted. When that local object is
constructed, it is constructed directly in the storage where the function's
return value would otherwise be moved or copied to. This variant of copy
elision is known as NRVO, "named return value optimization".
David.

Ah, "language lawyering." Thanks for the research. I suppose it makes
sense as a general rule. Where any conversion of the named return value is
needed, it might not be to a type occupying the same space on the stack.
Or in general conversions would have some effect on the bit pattern even if
same sized. Special-casing this stipulation to cover this casae of
unique_ptr may be too much to ask of the future standard.

PRL

Post by David Bailes

Post by Paul Licameli
PRL

Post by Paul Licameli
Aha, that document is edited by Stroustrup himself, and should repay study.
I will remove the unnecessary moves.
PRL