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

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.