Question

Possible Duplicate:
C++11 rvalues and move semantics confusion

What I think is correct is

std::string GetLine()
{
    std::string str;
    std::getline(std::cin, str);
    return std::move(str);
}

But at this link http://www.cprogramming.com/c++11/rvalue-references-and-move-semantics-in-c++11.html
( check the header part Returning an explicit rvalue-reference from a function)

which is #1 google search hit for move semantics shows a similar function signature as

int&& GetInt()
{
    int x = 0;
    // code here
    return std::move(x);
}

From what I read at other places && means rvalue reference so in this case its returning a reference to an object that doesn’t exist.

So which is it?

(Yes I know moving an int has no real benifit but the question is whether to use the return type of std::string or std::string&& in the first function. And if that is how it should be done for all types.)

Answer 1

You are absolutely correct that the int&& GetInt() example is wrong, and is returning a reference to an object that is destroyed. However, unless I missed it, the link you posted does not actually show any code returning a reference to a local variable. Instead I see a reference to a global variable being returned, which is okay.

Here is how you use move semantics when returning:

std::string func()
{
    std::string rv;
    /* ... */
    return rv;
}

You generally should not use std::move() when returning an object. The reason for this is that moving is already implicitly allowed anytime RVO could occur, and using std::move() will suppress RVO. So using std::move() will never be better and will often be worse than just returning normally.

---

Again, using std::move() can be worse than simply naming the variable to be returned because it suppresses the return value optimization. The return value optimization allows for an object to be returned to the caller without needing to copy that object

in a return statement in a function with a class return type, when
the expression is the name of a non-volatile automatic object (other
than a function or catch-clause parameter) with the same
cv-unqualified type as the function return type, the copy/move
operation can be omitted by constructing the automatic object directly
into the function’s return value

— [class.copy] 12.8/31

But using std::move() prevents the return expression from being the name of the object you’re returning. Instead the expression is more complicated and the language is no longer allowed to give it special handling.

The reason just naming the object is not worse than using std::move() is because there’s another rule that says an expression can already be treated as an rvalue without needing std::move().

When the criteria for elision of a copy operation are met or would be
met save for the fact that the source object is a function parameter,
and the object to be copied is designated by an lvalue, overload
resolution to select the constructor for the copy is first performed
as if the object were designated by an rvalue.