What is the post condition of a move constructor?

Question

Consider a class:

class foo {
public:
  foo(foo &&rhs) { /* some code */ }
  ~foo() noexcept { /* code that does destruction of owning objects */ }
private:
  /* some non-trivial pointer graph like structure */
};

Assume:

{
  foo &f = get_from_other_class();
  foo g = std::move(f);
  // some time later f goes our of scope or the owning object is destroyed.
}

What post conditions apply to f after std::move(f) has been executed?

Note

I have the suspicion that f must still be cleanly destructible (not destroying owning content of g) but I haven't found the corresponding quote in the C++11 standard. I'm skimming through 12.8 copying and moving class objects.

Answer 1

Every object must be destructible, unless you only ever allocate it dynamically. After having been "moved from", i.e. having its value bound to an rvalue reference (such as the first parameter of a move constructor), an object is still required to be valid and destructible, but typically it can be in an "unspecified" state and you are simply not supposed to look at the object any more and either let it go out of scope or reassign it.

Some types make stronger guarantees, for example std::unique_ptr promised that when move-constructing, it leaves the moved-from object in a state equal to nullptr.

The general idea behind rvalues and rvalue references is that an object that an rvalue should have no aliases, and specifically, when an object is bound to an rvalue reference, then there is no other alias of the object. The standard library makes those assumptions for the rvalue reference interfaces it exposes.

Answer 2

The post-condition is that your moved-from object is in an unspecified, but valid state. And it is precisely that: it is unspecified, meaning that it can be whatever you choose it to be (or the library implementor) as long as it is valid.

Answer 3

What post conditions apply to f after std::move(f) has been executed?

This can largely be dictated by the author of foo, but also constrained by the algorithms (std or not) that place requirements on foo.

Many algorithms will require that in its moved-from state foo be Destructible and can be assigned a new value. But this depends on the context in which foo will be used.

If foo is used with a std-library component, then the requirements are dictated by Table 20 -- MoveConstructible requirements:

rv’s state is unspecified [ Note:rv must still meet the requirements of the library compo- nent that is using it. The operations listed in those requirements must work as specified whether rv has been moved from or not. — end note ]

For example: Let's say you call std::sort with a vector<foo>. std::sort will require of foo: Swappable, MoveConstructible, Destructible, MoveAssignable, and LessThanComparable.

std::sort places these requirements on foo whether or not foo is in a moved-from state.

Strictly speaking one should not need to have foo be LessThanComparable when in a moved-from state if using with std::sort. It would be pointless for an implementor to compare a moved-from object since its value is unspecified. Nevertheless, the C++11 and C++14 standards currently require LessThanComparable. The result need not be sensible, but it is required to not crash if executed. A future standard might relax this requirement, but who knows.

So in summary, the author of foo can state what operations are allowed on a moved-from foo.

And any algorithm can state what it requires of the types it operates on.

In the intersection where foo meets the requirements of an algorithm, code works. The C++ standard does not consider a moved-from state special.

Answer 4

Table 20 (§ 17.6.3.1) defines MoveConstructible requirements:

+------------+----------------------------------------------------------------+
| Expression |                         Post-condition                         |
+------------+----------------------------------------------------------------+
| T u = rv;  | u is equivalent to the value of rv before the construction     |
| T(rv)      | T(rv) is equivalent to the value of rv before the construction |
+------------+----------------------------------------------------------------+

rv’s state is unspecified [ Note: rv must still meet the requirements of the library component that is using it. The operations listed in those requirements must work as specified whether rv has been moved from or not. — end note ]

The note indicates that per @Kerrek's answer that a library component may have different requirements.

Answer 5

The moved from object must be ready for a destructor to run.

Per Stroustrup, C++ Programming Language, 4th Edition 2014

If x is moved from, x will have "some moved-from state"...

"for the most interesting case, containers, that moved-from state is "empty" "...

I tend to consider it akin to a default initialized variable.

The value of builtin-types are unchanged after move.

The default moved-from state is one where the default destructor and the default copy assignment work correctly.

One of the definitions of that is if the destructor runs, any resource formerly managed by the object will no longer be managed by the object; the destructor will leave it alone, or be unaware. I suppose this is implementation / user dependent.

In short, you can do whatever correct thing you want with x and it shall be correct, as with a new variable.

Answer 6

since it is move, thus, after g = std::move(f);, semantic content of f should be invalidated, and g is validated. move only keeps one valid copy of semantic content.
the semantic of "invalidate/validate" depends on the class, for example, if f is a string, it should be set to be length of 0, if f is a thread, it should be set to std::thread(). However, the detailed behavior depends on the move constructor of the class.
surely f is still destructable.