What lasts after using std::move c++11

Solution 1:

The common mantra is that a variable that has been "moved-from" is in a valid, but unspecified state. That means that it is possible to destroy and to assign to the variable, but nothing else.

(Stepanov calls this "partially formed", I believe, which is a nice term.)

To be clear, this isn't a strict rule; rather, it is a guideline on how to think about moving: After you move from something, you shouldn't want to use the original object any more. Any attempt to do something non-trivial with the original object (other than assigning to it or destroying it) should be carefully thought about and justified.

However, in each particular case, there may be additional operations that make sense on a moved-from object, and it's possible that you may want to take advantage of those. For example:

• The standard library containers describe preconditions for their operations; operations with no pre­conditions are fine. The only useful ones that come to mind are clear(), and perhaps swap() (but prefer assignment rather than swapping). There are other operations without preconditions, such as size(), but following the above reasoning, you shouldn't have any business inquiring after the size of an object which you just said you didn't want any more.

• The unique_ptr<T, D> guarantees that after being moved-from, it is null, which you can exploit in a situation where ownership is taken conditionally:

  std::unique_ptr<T> resource(new T);
  std::vector<std::function<int(std::unique_ptr<T> &)> handlers = /* ... */;
  
  for (auto const & f : handlers)
  {
      int result = f(resource);
      if (!resource) { return result; }
  }
  

  A handler looks like this:

  int foo_handler(std::unique_ptr<T> & p)
  { 
      if (some_condition))
      {
          another_container.remember(std::move(p));
          return another_container.state();
      }
      return 0;
  }
  

  It would have been possible generically to have the handler return some other kind of state that indi­cates whether it took ownership from the unique pointer, but since the standard actually guaran­tees that moving-from a unique pointer leaves it as null, we can exploit that to transmit that information in the unique pointer itself.

Solution 2:

Move the member vector to a local vector, clear the member, return the local by value.

std::vector<string> stealVector() {
    auto ret = std::move(myVector);
    myVector.clear();
    return ret;
}

Solution 3:

What is left in myVector after the std::move?

std::move doesn't move, it is just a cast. It can happen that myVector is intact after the call to stealVector(); see the output of the first a.show() in the example code below. (Yes, it is a silly but valid code.)

If the guts of myVector are really stolen (see b = a.stealVector(); in the example code), it will be in a valid but unspecified state. Nevertheless, it must be assignable and destructible; in case of std::vector, you can safely call clear() and swap() as well. You really should not make any other assumptions concerning the state of the vector.

How would I recreate the vector, like a clear one?

One option is to simply call clear() on it. Then you know its state for sure.

The example code:

#include <initializer_list>
#include <iostream>
#include <string>
#include <vector>
using namespace std;

class A {
  public:
    A(initializer_list<string> il) : myVector(il) { }
    void show() {
      if (myVector.empty())
        cout << "(empty)";
      for (const string& s : myVector)
        cout << s << "  ";
      cout << endl;
    }
    vector<string>&& stealVector() {
      return std::move(myVector);
    }
  private:
    vector<string> myVector;        
};

int main() {
  A a({"a", "b", "c"});
  a.stealVector();
  a.show();
  vector<string> b{"1", "2", "3"};
  b = a.stealVector();
  a.show();
}

This prints the followings on my machine:

a b c
(empty)