What constitutes a valid state for a “moved from” object in C++11?

by

You define and document for your types what a ‘valid’ state is and what operation can be performed on moved-from objects of your types.

Moving an object of a standard library type puts the object into an unspecified state, which can be queried as normal to determine valid operations.

17.6.5.15 Moved-from state of library types                                        
[lib.types.movedfrom]

Objects of types defined in the C++ standard library may be moved from
(12.8). Move operations may be explicitly specified or implicitly
generated. Unless otherwise specified, such moved-from objects shall
be placed in a valid but unspecified state.

The object being in a ‘valid’ state means that all the requirements the standard specifies for the type still hold true. That means you can use any operation on a moved-from, standard library type for which the preconditions hold true.

Normally the state of an object is known so you don’t have to check if it meets the preconditions for each operation you want to perform. The only difference with moved-from objects is that you don’t know the state, so you do have to check. For example, you should not pop_back() on a moved-from string until you have queried the state of the string to determine that the preconditions of pop_back() are met.

std::string s = "foo";
std::string t(std::move(s));
if (!s.empty()) // empty has no preconditions, so it's safe to call on moved-from objects
    s.pop_back(); // after verifying that the preconditions are met, pop_back is safe to call on moved-from objects

The state is probably unspecified because it would be onerous to create a single useful set of requirements for all different implementations of the standard library.

Since you are responsible not only for the specification but also the implementation of your types, you can simply specify the state and obviate the need for querying. For example it would be perfectly reasonable to specify that moving from your pimpl type object causes do_stuff to become an invalid operation with undefined behavior (via dereferencing a null pointer). The language is designed such that moving only occurs either when it’s not possible to do anything to the moved-from object, or when the user has very obviously and very explicitly indicated a move operation, so a user should never be surprised by a moved-from object.

Also note that the ‘concepts’ defined by the standard library do not make any allowances for moved-from objects. That means that in order to meet the requirements for any of the concepts defined by the standard library, moved-from objects of your types must still fulfill the concept requirements. This means that if objects of your type don’t remain in a valid state (as defined by the relevant concept) then you cannot use it with the standard library (or the result is undefined behavior).

More Related Contents:

  1. What is “rvalue reference for *this”?
  2. push_back vs emplace_back
  3. C++11 rvalues and move semantics confusion (return statement)
  4. What is std::move(), and when should it be used?
  5. Can I list-initialize a vector of move-only type?
  6. initializer_list and move semantics
  7. When should std::move be used on a function return value? [duplicate]
  8. What is the advantage of using forwarding references in range-based for loops?
  9. How do I use a custom deleter with a std::unique_ptr member?
  10. Why is `std::move` named `std::move`?
  11. What does the standard library guarantee about self move assignment?
  12. C++11 move constructor not called, default constructor preferred
  13. Is a moved-from vector always empty?
  14. Move-only version of std::function
  15. How to actually implement the rule of five?
  16. How do I use unique_ptr for pimpl?
  17. Non-copyable elements in vector
  18. Can I typically/always use std::forward instead of std::move?
  19. Should I delete the move constructor and the move assignment of a smart pointer?
  20. copy vs std::move for ints
  21. Why do you use std::move when you have && in C++11? [duplicate]
  22. Do built-in types have move semantics?
  23. Is there any case where a return of a RValue Reference (&&) is useful?
  24. When to make a type non-movable in C++11?
  25. Is std::array movable?
  26. Should the Copy-and-Swap Idiom become the Copy-and-Move Idiom in C++11?
  27. Move out element of std priority_queue in C++11
  28. Should all/most setter functions in C++11 be written as function templates accepting universal references?
  29. Move semantics == custom swap function obsolete?
  30. Move constructor on derived object

Leave a Comment