Creating not copyable, but movable, objects in c++

Question

Just a question. Looking at C++ Boost libraries (in particular boost::thread class) I ended up thinking: "how is it possible to create a class defining objects that cannot be copied but that can be returned from a function?"

Well consider this example, the boost::thread class has the characteristics I mentioned before, so it is possible to do this:

boost::thread make_thread();

void f()
{
    boost::thread some_thread=make_thread();
    some_thread.join();
}

Well this means that the object boost::thread cannot be copied, but returned from a function, this is possible. How is this possible????

I suppose that a copy constructor must not be provided, but how to deal with returning from a function? doesn't it need to use a copy constructor???

Thankyou

Answer 1

This is possible starting with C++11, which provides move semantics via rvalue references. Using this you can implement moving and/or copying separatedly:

class my_class {
  private:
    data_t* data_;
  public:
    my_class(const my_class& rhs)      // copy constructor
     : data_(rhs.data_.clone())
    {}
    my_class(my_class&& rhs)           // move constructor
     : data_(rhs.data_)
    {
      rhs.data_ = NULL;
    }
    ~my_class() {delete data_;}        // noop if data_==NULL

    my_class& operator=(my_class rhs)  // copy assignment
    {
      this->swap(rhs);
    }
    my_class& operator=(my_class&& rhs)// move assignment
    {
      this->swap(rhs);
    }

    // ...
};

Copying and moving can be forbidden separately, so you can setup classes that can be moved, but not copied.

Of course, there are a few magical tricks that let you do this even when your compiler doesn't yet support move semantics (std::auto_ptr, after all moves instead of copying when assigned to), so this might work for boost::thread even in the absence of move semantics.

Answer 2

This is an advanced topic of C++ if you want to do this in C++03. See Howard Hinnants Unique_ptr C++03 emulation for an example of that.

It basically works by abusing several subtle rules in C++ overload resolution, in particular the rule that non-const references cannot bind to rvalue temporaries and that non-const conversion functions can still be called on non-const temporaries.

You can also use the auto_ptr technique as employed by C++03, which however is seen as broken by several groups because auto_ptr lets you copy variables, but steal resources from the copied-from object (other groups have other opinions about this).