Should the moved-from object be left in a "safe" state?

Possible Duplicate:
How can moved objects be used?
What constitutes a valid state for a “moved from” object in C++11?

When implementing move semantics in C++11, should the moved-from object be left in a safe state, or can it be just left in a "junk" state?

e.g. What is the preferred option to implement move constructor in the following example of a C++11 wrapper to a raw FILE* resource?

// C++11 wrapper to raw FILE*
class File
{
  FILE* m_fp;

public:

  // Option #1
  File(File&& other)
    : m_fp(other.m_fp)
  {
    // "other" left in a "junk" state
  }

  // Option #2
  File(File&& other)
    : m_fp(other.m_fp)
  {
    // Avoid dangling reference in "other"
    other.m_fp = nullptr;
  }

  ...
};

c++ c++11 move-semantics

Edit Report

The only thing you must be able to do with a moved-from object is destroy it. Beyond that, it's up to your class what the normal class invariants are and whether moved-from objects bother to satisfy them.

For example, it's a good idea to ensure that you can assign to the object, just in case someone wants to use std::move on an instance and give it a new value later. [Edit: as pointed out in an answer to one of the suggested-dupe questions, the general std::swap template moves from an object and then move-assigns to it, so if you don't ensure this then either you need to specialize std::swap or you need to forbid users of your class from using it.]

Since your class does nothing in its destructor, either option is fine. Option 2 might be easier for users to work with, but then again if they're coding on the assumption that they can't do anything with a moved-from object, then it makes no difference. Since the class is incomplete, though, that might change when you write the destructor.

answered 2012-10-30T11:22:08.327

Should the moved-from object be left in a "safe" state?

1 Answer

Your Answer