c++ - How to define a move constructor?

Question

I am trying some new C++11 features on visual studio 11, started with the move constructor. I wrote a simple class called "MyClass" containing a move constructor:

class MyClass
{
public:
    explicit MyClass( int aiCount ) 
        : mpiSize( new int( aiCount ) ),
          miSize2( aiCount)
    {
    }

    MyClass( MyClass&& rcOther )
        : mpiSize( rcOther.mpiSize )
        , miSize2( *rcOther.mpiSize )
    {
       rcOther.mpiSize = 0;
       rcOther.miSize2 = 0;
    }

    ~MyClass() 
    {
        delete mpiSize;
    }

private:
    int *mpiSize;
    int miSize2;

};

I got there questions here:

1. I assumed that the compiler would generate a move constructor for MyClass if I don't implement one - but it doesn't seems so?
2. Is the implementation of the move constructor correct for MyClass?
3. Is there a better way to implement the move constructor for MyClass?

Answer 1

1. MSVC++ implemented move constructors before the final version of the standard was out. In the version of the standard MSVC++'s implementation was based on, the rules for generating a default move constructor were ridiculously more strict than they are in the final version of the standard. See here: Why is this code trying to call the copy constructor? (specifically this answer and the comments on it) for more info on that. This has not been and will not be fixed in Visual Studio 11, for some unknown stupid reason because they had other priorities.

2. No, you need to call std::move on the members of rcOther, and you initialise members with the corresponding members from the dying object (you misnamed miSize):

   MyClass( MyClass&& rcOther )
       : mpiSize( std::move(rcOther.mpiSize) )
       , miSize2( std::move(rcOther.miSize2) )
   {
      rcOther.mpiSize = 0;
   }
   

   It doesn't make a difference for built in types like int and int*, but it definitely makes a difference for user-defined types.

   • _{The reason for this is that std::move just returns the argument casted into a T&&, an rvalue-reference, so that the correct constructor (the move constructor, T(T&&)) is called for each of the sub-objects. If you don't use std::move on the members of the dying object, they will be treated like T&, and the copy constructor of your subobjects (T(T&)) will be called instead of the move constructor. That is very bad and thwarts almost the entire purpose of you having written a move constructor.}

3. You are doing some unnecessary things, like setting the integer to 0. You only need to set the pointer to 0 so that deleteing it won't delete the resource of the new object you created.

Also, if this is not a didactic exercise, you may want to consider using std::unique_ptr instead of managing the lifetime of your own object. This way you don't even have to write a destructor for your class. Note that if you do that, using std::move to initialise the member from the dying member in the move constructor would be mandatory.

---

• Konrad Rudolph in his answer has caught the fact that your class manages a non-automatic resource but does not follow the Rule of Five Three, Four, or Five. See his answer for more details on this.