How would move semantics improve "my way"?

Question

Background

I read the following answers earlier today, and it felt like relearning C++, litterally.

What are move semantics?

What is the copy-and-swap idiom?

Then I wondered if I should change my "ways" to use these exciting features; the main concerns I have are for code efficiency and clarity (former slightly more important than the latter to me). This lead me to this post:

Why have move semantics?

with which I strongly disagree (I agree with the answer, that is); I don't think a smart use of pointers could ever make move semantics redundant, neither in terms of efficiency nor clarity.

Question

Currently, whenever I implement a non-trivial object, I roughly do this:

struct Y
{
    // Implement
    Y();
    void clear();
    Y& operator= ( const& Y );

    // Dependent
    ~Y() { clear(); }

    Y( const Y& that )
        : Y()
    {
        operator=(that);
    }

    // Y(Y&&): no need, use Y(const Y&)
    // Y& operator=(Y&&): no need, use Y& operator=(const Y&)
};

From what I understand from the two first posts I read today, I am wondering whether it would be beneficial to change to this instead:

struct X
{
    // Implement
    X();
    X( const X& );

    void clear();
    void swap( X& );

    // Dependent
    ~X() { clear(); }

    X( X&& that )
        : X()
    {
        swap(that);
        // now: that <=> X()
        // and that.~X() will be called shortly
    }

    X& operator= ( X that ) // uses either X( X&& ) or X( const X& )
    { 
        swap(that); 
        return *this; 
        // now: that.~X() is called
    }

    // X& operator=(X&&): no need, use X& operator=(X)
};

Now, aside from being slightly more complicated and verbose, I don't see a situation in which the second (struct X) would yield a performance improvement, and I find that it is also less readable. Assuming my second code is using move-semantics correctly, how would it improve my current "way" of doing things (struct Y)?

---

Note 1: The only situation which I think makes the latter clearer is for "moving out of function"

X foo()
{
    X automatic_var;
    // do things
    return automatic_var;
}
// ...
X obj( foo() );

for which I think the alternative using std::shared_ptr, and std::reference_wrapper if I get tired of get()

std::shared_ptr<Y> foo()
{
    std::shared_ptr<Y> sptr( new Y() );
    // do things
    return sptr;
}
// ...
auto sptr = foo();
std::reference_wrapper<Y> ref( *ptr.get() );

is only slightly less clear, but as efficient.

Note 2: I really made an effort to make this question precise and answerable, and not subject to discussion; please think it through and don't interpret it as "Why are move-semantics useful", this is not what I am asking.

Answer 1

Currently, whenever I implement a non-trivial object, I roughly do this...

I trust you abandon that when there are more complex data members - e.g. types that perform some calibration, data generation, file I/O, or resource acquisition during default construction, only to be thrown away / released on (re)assignment.

I don't see a situation in which the second (struct X) would yield a performance improvement.

Then you don't understand move semantics yet. I assure you such a situation exists. But given '"Why are move-semantics useful", this is not what I am asking.' I'm not going to explain them to you again here in the context of your own code... go "please think it through" yourself. If thinking fails you again, try adding a std::vector<> to many MBs of data and benchmark.

Answer 2

std::shared_ptr stores your data on the free store (runtime overhead), and has a thread safe atomic increment/decrement (runtime overhead), and is nullable (either ignore it and get bugs, or check it constantly for runtime and programmer time overhead), and has a non-trivial to predict lifetime of the object (programmer overhead).

It is not in any way, shape or form as cheap as a move.

Move occurs when NRVO and other forms of elision fail, so if you have a cheap move using objects as values means you can rely on elision. Without cheap move, relying on elision is dangerous: elision is both fragile in practice and not guaranteed by the standard.

Having efficient move also makes containers of objects efficient without having to store containers of smart pointers.

A unique pointer solves some of the problems with shared pointer, except forced free store and nullability, and it also blocks easy use of copy construction.

As an aside, there are issues with your planned move-capable pattern.

First, you needlessly default construct before move constructing. Sometimes the default construct is not free.

Second operator=(X) does not play nice with some defects in the standard. I forget why -- composition or inheritance issue? -- I will try to remember to come back and edit it in.

If default construct is nearly free, and swapping is element-wise, here is a C++14 approach:

struct X{
  auto as_tie(){
    return std::tie( /* data fields of X here with commas */ );
  }
  friend void swap(X& lhs, X& rhs){
    std::swap(lhs.as_tie(), rhs.as_tie());
  }
  X();// implement
  X(X const&o):X(){
    as_tie()=o.as_tie();
  }
  X(X&&o):X(){
    as_tie()=std::move(o.as_tie());
  }
  X&operator=(X&&o)&{// note: lvalue this only
    X tmp{std::move(o)};
    swap(*this,o);
    return *this;
  }
  X&operator=(X const&o)&{// note: lvalue this only
    X tmp{o};
    swap(*this,o);
    return *this;
  }
};

now if you have components that need manual copying (like a unique_ptr) the above does not work. I'd just write a value_ptr myself (that is told how to copy) to keep those details away data consumers.

The as_tie function also makes == and < (and related) easy to write.

If X() is non-trivial, both X(X&&) and X(X const&) can be written manually and efficiency regained. And as operator=(X&&) is so short, having two of them is not bad.

As an alternative:

X& operator=(X&&o)&{
  as_tie()=std::move(o.as_tie());
  return *this;
}

is another implementation of = that has its pluses (and ditto for const&). It can be more efficient in some cases, but has worse exception safety. It also eliminates the need for swap, but I would leave swap in regardless: element-wise swap is worth it.

Answer 3

Adding to what others have said:

You should not implement a constructor by calling operator= . You do that with:

Y( const Y& that ) : Y()
{
    operator=(that);
}

The reason to avoid this is that it requires default-constructing a Y (which doesn't even work if Y doesn't have a default constructor); and also it will pointlessly create and destroy any resources which might be allocated by the default constructor.

You correctly fix this for X by using the copy-and-swap idiom but then you introduce a similar mistake:

X( X&& that ) : X()
{
    swap(that);

The move-constructor should construct, not swap. Again there is a pointless default-construction and then destruction of any resources that the default constructor might have allocated.

You will have to actually write the move constructor to move each member. It needs to be correct so that your unified copy/move-assignment works.

---

A more general comment: you should be doing all of this very rarely. This is how you create a RAII wrapper for something; your more complicated objects should be made out of RAII-compatible subobjects so that they can follow the Rule of Zero. In most cases there are pre-existing wrappers such as shared_ptr so you do not have to write your own.

Answer 4

One notable improvement is when a function 'consumes' or otherwise works with a parameter (ie: takes by value rather than by reference). In that case, without the move semantics, passing in some lvalue as a parameter would force a copy.

The move semantics give the caller the choice of having the function copy the value (despite being potentially costly) or 'move' the value into the function knowing that after this call it has no more use for the lvalue which was passed in.

Additionally if a function uses a shared_ptr (or other wrapper which requires an allocation) just for the sake of being able to move the return value out, using move semantics then gets rid of that allocation. So it's more than just a nicety but also a perf boost.

While it is quite easy to write code that does not make use of move semantics and retains efficiency, using move semantics allows the users of the type which supports them to have simpler interfaces and use cases (by basically always using value semantics).

EDIT:

Since the OP specifically calls out efficiency, it's worth adding that move semantics can at best reach the same efficiency as could be achieved without them.

As far as I know, for any given code snippet where the addition of std::move would give a performance benefit vs not having it, simply reworking the code can match the best efficiency of the move or even beat it.

One recent bit of code I wrote was a producer which iterated over some data, selecting and transforming to fill up a buffer for a consumer. I wrote a little generic gimmick of sorts which abstracted capturing the data and shunting it off to a consumer.

The consumer was either same-thread (ie: dealt with as the producer piped it through), another thread (standard single-thread consumer deal), or multi-thread for PC platform.

In this case the producer code looked rather neat and simple as it filled a container and std::move'd it into the consumer via the aforementioned mechanism which was defined per platform.

If one were to suggest that this could be done to the same effect without using move semantics, one would be quite right. It just afforded me to have - what I thought - was simpler code. Ordinarily the price I'd pay is yet more cruft in the definition of the object, but in this case it was a std container so someone else did that work ;)