Does moving a vector invalidate iterators?

Question

If I have an iterator into vector a, then I move-construct or move-assign vector b from a, does that iterator still point to the same

Answer 1

tl;dr : Yes, moving a std::vector possibly invalidates the iterators

_{The common case (with std::allocator in place) is that invalidation does not happen but there is no guarantee and switching compilers or even the next compiler update might make your code behave incorrect if you rely on the fact the your implementation currently does not invalidate the iterators.}

---

On move assignment:

The question whether std::vector iterators can actually remain valid after move-assignment is connected with the allocator awareness of the vector template and depends on the allocator type (and possibly the respective instances thereof).

In every implementation I have seen, move-assignment of a std::vector>¹ will not actually invalidate iterators or pointers. There is a problem however, when it comes down to making use of this, as the standard just cannot guarantee that iterators remain valid for any move-assignment of a std::vector instance in general, because the container is allocator aware.

Custom allocators may have state and if they do not propagate on move assignment and do not compare equal, the vector must allocate storage for the moved elements using its own allocator.

Let:

std::vector a{/*...*/};
std::vector b;
b = std::move(a);

Now if

1. std::allocator_traits::propagate_on_container_move_assignment::value == false &&
2. std::allocator_traits::is_always_equal::value == false && (possibly as of c++17)
3. a.get_allocator() != b.get_allocator()

then b will allocate new storage and move elements of a one by one into that storage, thus invalidating all iterators, pointers and references.

The reason is that fulfillment of above condition 1. forbidds move assignment of the allocator on container move. Therefore, we have to deal with two different instances of the allocator. If those two allocator objects now neither always compare equal (2.) nor actually compare equal, then both allocators have a different state. An allocator x may not be able to deallocate memory of another allocator y having a different state and therefore a container with allocator x cannot just steal memory from a container which allocated its memory via y.

If the allocator propagates on move assignment or if both allocators compare equal, then an implementation will very likely choose to just make b own as data because it can be sure to be able to deallocate the storage properly.

¹: std::allocator_traits>::propagate_on_container_move_assignment and std::allocator_traits>::is_always_equal both are typdefs for std::true_type (for any non-specialized std::allocator).

---

On move construction:

std::vector a{/*...*/};
std::vector b(std::move(a));

The move constructor of an allocator aware container will move-construct its allocator instance from the allocator instance of the container which the current expression is moving from. Thus, the proper deallocation capability is ensured and the memory can (and in fact will) be stolen because move construction is (except for std::array) bound to have constant complexity.

Note: There is still no guarantee for iterators to remain valid even for move construction.

---

On swap:

Demanding the iterators of two vectors to remain valid after a swap (now just pointing into the respective swapped container) is easy because swapping only has defined behaviour if

1. std::allocator_traits::propagate_on_container_swap::value == true ||
2. a.get_allocator() == b.get_allocator()

Thus, if the allocators do not propagate on swap and if they do not compare equal, swapping the containers is undefined behaviour in the first place.