在 c++11 中，函数中返回的 std::string 是移动还是复制？

Question

suppose I have the following code.

std::string foo() {
    std::string mystr("SOMELONGVALUE");
    return mystr;
}

int main() {
    std::string result = foo();
}

When I call 'foo', is the data in mystr copied or moved into result ? I believe that it is moved C++11 style, but I was hoping for clarification and/or links to show that.

Thanks!

Edit: I suppose I want to know the answer to this question when compiling with g++ for c++11 or later.

Answer 1

Your example fall on the so-called Named Return Value Optimization, which is defined in this paragraph of the C++11 standard . So the compiler may elide the copy constructor (or move constructor since C++14). This elision is not mandatory.

In C++11 , if the compiler does not perform this elision, the returned string will be copy constructed . The returned object would be moved if it were naming a function parameter, [class.copy]/32 (bold is mine):

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 . [...]

In C++14, this last rule has changed. It also includes the case of automatic variables [class.copy]/32 :

When the criteria for elision of a copy/move operation are met, but not for an exception-declaration, and the object to be copied is designated by an lvalue, or when the expression in a return statement is a (possibly parenthesized) id-expression that names an object with automatic storage duration declared in the body or parameter-declaration-clause of the innermost enclosing function or lambda-expression, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue . [...]

So in your example code, and in C++14 , if the compiler does not elide the copy/move construction, the returned string will be move constructed .

Answer 2

Like user4581301 said, I suspect copy elision to happen (not a move) in most implementations. For c++11 and c++14, the standard allows copy elision to happen but doesn't mandate it. In c++17, some instances of copy elision will become mandated. So, for c++11 and c++14, technically the answer depends on the implementation being used. In your case specifically, we're talking about a specific type of copy elision: return value optimization (RVO). To check whether RVO happens in your environment for your given case, you can run this code:

#include <iostream>

struct Foo {
  Foo() { std::cout << "Constructed" << std::endl; }

  Foo(const Foo &) { std::cout << "Copy-constructed" << std::endl; }

  Foo(Foo &&) { std::cout << "Move-constructed" << std::endl; }

  ~Foo() { std::cout << "Destructed" << std::endl; }
};

Foo foo() {
    Foo mystr();
    return mystr;
}

int main() {
    Foo result = foo();
}

My implementation opts for RVO - no move takes place.

Answer 3

Since std::string result = foo(); is an initializer, it will call the constructor rather than the assignment operator. In C++11 or newer, there is guaranteed to be a move constructor with prototype std::basic_string::basic_string( basic_string&& other ) noexcept . On every actually-existing implementation, this moves the contents rather than copying them. Although I don't believe the standard mandates a particular implementation, it does say this particular operation must run in constant and not linear time, which precludes a deep copy. As the return value of foo() is a temporary rvalue, that is the constructor that will be called in this snippet.

So, yes, this code will move the string rather than copy it.

The expression in a return statement will not always be copied, however. If you return std::string("SOMELONGVALUE"); (a programmatic constructor ), the implementation is permitted to construct the result in place instead. If foo() returns a std::string& and returns anything other than a temporary, that will be returned by reference. (Returning a reference to a temporary that's been destroyed is, as you know, undefined behavior!) And some compilers, even before C++11, would perform copy elision and avoid creating a temporary only to copy and destroy it. Newer versions of the Standard make copy elision mandatory in most situations where it's possible, but compilers were doing it even before that.

Answer 4

The way the most compilers implement return of a class type is to pass an extra "hidden" argument to the function that is a pointer to the memory where the value being returned should be constructed. So the called function can copy or move the return value into that memory as needed without regard to the call site.

With your example code, such a compiler could even use that same memory to hold the mystr variable, constructing it directly there, and never using either the move or copy constructor of std::string.

Answer 5

In my VS2015, the compiler does invoke move ctor when returning an temp variable in such a trivial case.

class A {
public:
    A(int _x) :x(_x) {}
    A(const A& a) {
        cout << "copy ctor." << endl;
        x = a.x;
    }
    A(A&& a) {
        cout << "move ctor." << endl;
        x = 123;
    }
    private:
        int x;
    };

A foo() {
    A temp = { 7 };
    return temp;         //invoke move ctor
}


int main() {
    A a = foo();
    return 0;
}

Besieds, whether the compiler trigger RVO depends on the price of copying, you can see the mechanism of RVO in below: https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/RVO_V_S_std_move?lang=en