What does the standard library guarantee about self move assignment?

by

17.6.4.9 Function arguments [res.on.arguments]

1 Each of the following applies to all arguments to functions defined
in the C++ standard library, unless explicitly stated otherwise.

…

  • If a function argument binds to an rvalue reference parameter, the implementation may assume that this parameter is a unique reference to
    this argument. [ Note: If the parameter is a generic parameter of the
    form T&& and an lvalue of type A is bound, the argument binds to an
    lvalue reference (14.8.2.1) and thus is not covered by the previous
    sentence. — end note ] [ Note: If a program casts an lvalue to an
    xvalue while passing that lvalue to a library function (e.g. by
    calling the function with the argument move(x)), the program is
    effectively asking that function to treat that lvalue as a temporary.
    The implementation is free to optimize away aliasing checks which
    might be needed if the argument was anlvalue. —endnote]

So, the implementation of std::vector<T, A>::operator=(vector&& other) is allowed to assume that other is a prvalue. And if other is a prvalue, self-move-assignment is not possible.

What is likely to happen:

v will be left in a resource-less state (0 capacity). If v already has 0 capacity, then this will be a no-op.

Update

The latest working draft, N4618 has been modified to clearly state that in the MoveAssignable requirements the expression:

t = rv

(where rv is an rvalue), t need only be the equivalent value of rv prior to the assignment if t and rv do not reference the same object. And regardless, rv‘s state is unspecified after the assignment. There is an additional note for further clarification:

rv must still meet the requirements of the library component that is using it, whether or not t and rv refer to the same object.

More Related Contents:

  1. push_back vs emplace_back
  2. Non-copyable elements in vector
  3. What is move semantics?
  4. How to enforce move semantics when a vector grows?
  5. What can I do with a moved-from object?
  6. Reusing a moved container?
  7. Why no default move-assignment/move-constructor?
  8. Move assignment operator and `if (this != &rhs)`
  9. What are the rules for automatic generation of move operations?
  10. Why is template argument deduction disabled with std::forward?
  11. Why use non-member begin and end functions in C++11?
  12. Why does std::move prevent RVO (return value optimization)?
  13. How does std::move() transfer values into RValues?
  14. Does moving leave the object in a usable state?
  15. Is it possible to std::move objects out of functions? (C++11)
  16. Why do some people use swap for move assignments?
  17. Initializer-list-constructing a vector of noncopyable (but movable) objects
  18. Is a `=default` move constructor equivalent to a member-wise move constructor?
  19. Is an object guaranteed to be moved when it is returned?
  20. C++11 STL containers and thread safety
  21. Move or Named Return Value Optimization (NRVO)?
  22. C++11 virtual destructors and auto generation of move special functions
  23. Comparing 3 modern c++ ways to convert integral values to strings
  24. When is explicit move needed for a return statement?
  25. Are lambdas inlined like functions in C++?
  26. Should all/most setter functions in C++11 be written as function templates accepting universal references?
  27. Why vector access operators are not specified as noexcept?
  28. Move semantics == custom swap function obsolete?
  29. Move constructor on derived object
  30. Can the ‘type’ of a lambda expression be expressed?

Leave a Comment