Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

When should compiler generate move constructor?

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 ?

like image 593
Ghita Avatar asked Nov 01 '12 10:11

Ghita


People also ask

Why do we need move constructor?

A move constructor enables the resources owned by an rvalue object to be moved into an lvalue without copying. For more information about move semantics, see Rvalue Reference Declarator: &&. This topic builds upon the following C++ class, MemoryBlock , which manages a memory buffer.

How do move constructors work?

Move constructor moves the resources in the heap, i.e., unlike copy constructors which copy the data of the existing object and assigning it to the new object move constructor just makes the pointer of the declared object to point to the data of temporary object and nulls out the pointer of the temporary objects.

What does std :: move () do?

std::move is used to indicate that an object t may be "moved from", i.e. allowing the efficient transfer of resources from t to another object. In particular, std::move produces an xvalue expression that identifies its argument t . It is exactly equivalent to a static_cast to an rvalue reference type.

Why should move constructor be Noexcept?

noexcept is nice for two reasons: The compiler can optimize a little better because it doesn't need to emit any code for unwinding a call stack in case of an exception, and. It leads to incredible performance differences at runtime for std::vector (and other containers, too)


1 Answers

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).

like image 147
Howard Hinnant Avatar answered Sep 18 '22 15:09

Howard Hinnant