Question

I use VS11 and use following:

class ContextWrapper
{
public:

    ContextWrapper()
    {
    } //it should be defaulted I *guess* in order to have automatic move constructor ?
      // no support in VS11 for that now  

    Context* GetContext()
    {
        return this->context.get();
    }

    void SetContext(std::unique_ptr<Context> context)
    {
        this->context = std::move(context);
    }

    //ContextWrapper(ContextWrapper&& other):  context(std::move(other.context))
    //{
    //} // I would like this to be generated by the compiler

private:
    ContextWrapper(const ContextWrapper&);
    ContextWrapper& operator= (const ContextWrapper&);

    std::unique_ptr<Context> context;
};

I would like this class to have generated move constructor/assignment. Is the fact that I don’t have a trivial constructor the reason I don’t get move ? Or there are other factors that influence this ?

Answer 1

This part of C++11 is unfortunately in flux. And whatever the standard is going to say, VC11 couldn’t possibly implement it yet. So for today, I don’t believe you’ll be able to count on generated move members.

However, this is a good question and I wanted to get a good answer out on it.

In general, the compiler should generate move members if you have no user-declared copy members nor destructor. = default and = delete counts as user-declared. If you declare one move member (e.g. move constructor), the other will not be implicitly generated.

Unfortunately C++11 goes on to say that sometimes the move members are implicitly deleted when declared with =default, and sometimes their generation depends upon whether the bases and members have move members or are trivially copyable. This is all way too complicated and sometimes gives surprising behavior. Here is the CWG issue tracking this bug:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1402

As I write this, the issue does not have the correct proposed resolution. I expect that to change in about a week. At the 2012 Fall C++ standards meeting in Portland, OR, an agreement was reached which basically says:

1. The compiler will never implicitly delete move members.
2. The implicit generation of the move members will always be the same thing as = default.
3. Implicit generation will not depend upon the triviality of the bases or members, nor whether or not they may throw when moved.

In a nutshell, I expect the corrected wording of CWG 1402 to simply say:

In general, the compiler should generate move members if you have no
user-declared copy members nor destructor. = default and = delete
counts as user-declared. If you declare one move member (e.g. move
constructor), the other will not be implicitly generated.
And if you =default a move member, you’ll get something that moves
each base and member.

(in proper standardize). I have not yet seen the wording that will say this. Jason Merrill is writing it up for us.

This will mean that sometimes the compiler will implicitly generate throwing move members. But we were going for simple rules that nevertheless did the right thing most of the time (few surprises).