Compiler not generating move constructors

Question

I am trying to understand the move semantics are looking in to compiler generated move constructors (copy and assignment). In Modern Effective C++, Scott Meyers says in Item #17 that if no explicit copy constructors are declared, the the compiler will generate move constructors, which will do member-wise move for non-static members.

To confirm this, I am trying below code:

#include <iostream>
#include <string>
using namespace std;

class A
{
private:
    std::string str;

public:

    A() : str("Init string")
    {
        cout << "Default constructor" << endl;
    }

    A(std::string _str) : str(_str)
    {
        cout << "Constructor with string" << endl;
    }

    std::string getString()
    {
        return str;
    }
};

int main() {

    A obj1;
    A obj2("Obj2 string");

    cout << endl;
    cout << "obj1: " << obj1.getString() << endl;
    cout << "obj2: " << obj2.getString() << endl;

    obj1 = std::move(obj2);

    cout << endl;
    cout << "obj1: " << obj1.getString() << endl;
    cout << "obj2: " << obj2.getString() << endl;

    return 0;
}

The output is:

Default constructor
Constructor with string

obj1: Init string
obj2: Obj2 string

obj1: Obj2 string
obj2: Obj2 string

But I expected it to be:

Default constructor
Constructor with string

obj1: Init string
obj2: Obj2 string

obj1: Obj2 string
obj2:

Because obj2.str would have been moved and now has an empty string.

What is the reason the compiler is not generating a move assignment constructor and invoking the copy assignment operator?

EDIT: Implementing the move assignment operator as below gives the expected output (i.e. empty string after calling std::move)

A& operator=(A&& obj)
    {
        cout << "Move assignment operator" << endl;
        str = std::move(obj.str);
        return *this;
    }

Note that mid-2010s versions of MSVC didn't generate move constructors when they should have — M.M, Nov 14 '18 at 02:49

songyuanyao · Accepted Answer · 2018-11-14T07:48:27.307

7

Firstly, obj1 = std::move(obj2); invokes assignment operator, so it has nothing to do with constructors.

Yes, The compiler generates a move assignment operator for A, which perform member-wise move operation, including data member str. The problem is that after move operation str is left in valid, but unspecified state. Also see std::basic_string::operator=.

Replaces the contents with those of str using move semantics. str is in a valid but unspecified state afterwards.

I think you might observe the same result with only std::string, e.g.

std::string str1 = "Init string";
std::string str2 = "Obj2 string";
str1 = std::move(str2);
std::cout << str2;

LIVE with clang, just for reference; it gives the result as you expected but still remember the result is unspecified.

edited Nov 14 '18 at 07:48

answered Nov 14 '18 at 02:47

songyuanyao

169,198
16
310
405

Thank you. However, I see that when I implement the move assignment constructor, obj1 = std::move(obj) invokes that explicitly declared move assignment constructor, NOT the copy assignment operator. – madu Nov 14 '18 at 04:10
@madu How did you declare the *move assignment constructor* ? What's its signature? – songyuanyao Nov 14 '18 at 04:12
The signature is A& operator=(A&& obj). Wrong? – madu Nov 14 '18 at 04:13
@madu I see, yes this is assignment operator. :) Move constructor looks like `A(A&& obj)`. They're different. So we don't say *assignment constructor*, which is confusing. – songyuanyao Nov 14 '18 at 04:15
Thanks. Yes, I see the difference. But the signature is correct for the move assignment operator, right? – madu Nov 14 '18 at 04:20

score 3 · Answer 2 · answered Nov 14 '18 at 02:44

3

The compiler is invoking the move-assignment operator, which causes obj1.str to be move-assigned from obj2.str. However, a move does not guarantee that the source object is empty; for most standard library classes, an object that has been moved from is left in a "valid but unspecified state". (The most obvious exception is that a std::unique_ptr<T> that has been moved from is guaranteed to be null.) It will often, but not always, be the case that a moved-from std::string is empty. In your case, the string "Obj2 string" is short enough that it might be stored inline (i.e., using the short string optimization). If that's the case, then the move-assignment operator must copy the string. Going back and emptying out the source string would then add extra overhead, so the implementation doesn't do it.

answered Nov 14 '18 at 02:44

Brian Bi

111,498
10
176
312

Thank you Brian. But, when I explicitly implement move assignment operator and inside it do str = std::move(obj.str), I see that obj2.str is infact the empty string. Why do I see a different behavior in that case? – madu Nov 14 '18 at 04:11
@madu Can you provide steps required to reproduce *both* behaviours, i.e., with and without the user-provided move-assignment operator? – Brian Bi Nov 14 '18 at 05:37
Thanks @Brian. I edited the original question and included the move assignment operator implementation that would give the output I am expecting. – madu Nov 14 '18 at 06:06

score 2 · Answer 3 · edited Jun 20 '20 at 09:12

The standard does not specify the state of a moved from object.

17.6.5.15 Moved-from state of library types [lib.types.movedfrom]

Objects of types defined in the C++ standard library may be moved from (12.8). Move operations may be explicitly specified or implicitly generated. Unless otherwise specified, such moved-from objects shall be placed in a valid but unspecified state.

So your moved from string is in a valid but unspecified state. Do not except an empty string or the same value or a string containing "potato".

My guess here is that "Obj2 string" fits in the small string optimisation, which enable small strings to live on the stack instead of the heap. In this particular case, assigning by memcpy the string object to the other without any cleanup (eg, without setting the old string to empty) is actually faster.

Compiler not generating move constructors

3 Answers3