std::move in return statements

Question

I've been paying close attention to the advice never to write std::move in a return statement, for example. Except there are some edge cases, for example.

I believe the following is another simple example of where std::move may be worthwhile - did I miss something? But I'm not sure why, and will that change in a future C++?

#include <iostream>

struct A
{
};

struct C
{
};

struct B
{
    B(const A&, const C&) { std::cout << "B was copied\n"; }
    B(A&&, C&&) { std::cout << "B was moved\n"; }
};

B f()
{
    A a;
    C c;
    //return {a, c}; // Gives "B was copied"
    return {std::move(a), std::move(c)}; // Gives "B was moved"
}

int main() {
    f();
    return 0;
}

You aren't trying to force move the returned object, you are constructing it. It's not related to the advice. — StoryTeller - Unslander Monica, Oct 10 '17 at 12:27
Those different constructors don't have anything to do with `B` being moved or copied. — John, Oct 10 '17 at 12:28
your code is quite different from a `return std::move(x);`. What you move here is actually rather unrelated to the return — 463035818_is_not_an_ai, Oct 10 '17 at 12:28
It isn't `B` that is moved or copied, it is `A` and `C`. It is your texts that are incorrect. — Bo Persson, Oct 10 '17 at 13:23

score 7 · Accepted Answer · answered Oct 10 '17 at 12:29

return {std::move(a), std::move(c)}

is equivalent to

return B{std::move(a), std::move(c)}

You're basically invoking B::B(A&&, C&&) instead of the version taking const& references. This has nothing to do with moving a return value.

The return value of the function is the temporary instance of B, which is a prvalue. It C++17, it will benefit from "guaranteed copy elision". Before C++17, it will be RVOd or moved into its target.

std::move in return statements

1 Answers1