This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.
Section: 24.3.8.4 [deque.modifiers] Status: CD1 Submitter: Steve LoBasso Opened: 2007-02-17 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [deque.modifiers].
View all issues with CD1 status.
Discussion:
The standard states at 24.3.8.4 [deque.modifiers]/4:
deque erase(...)Effects: ... An erase at either end of the deque invalidates only the iterators and the references to the erased elements.
This does not state that iterators to end will be invalidated. It needs to be amended in such a way as to account for end invalidation.
Something like:
Any time the last element is erased, iterators to end are invalidated.
This would handle situations like:
erase(begin(), end()) erase(end() - 1) pop_back() resize(n, ...) where n < size() pop_front() with size() == 1
[ Post Kona, Steve LoBasso notes: ]
My only issue with the proposed resolution is that it might not be clear that pop_front() [where size() == 1] can invalidate past-the-end iterators.
[ Kona (2007): Proposed wording added and moved to Review. ]
[ Bellevue: ]
Note that there is existing code that relies on iterators not being invalidated, but there are also existing implementations that do invalidate iterators. Thus, such code is not portable in any case. There is a pop_front() note, which should possibly be a separate issue. Mike Spertus to evaluate and, if need be, file an issue.
Proposed resolution:
Change 24.3.8.4 [deque.modifiers], p4:
iterator erase(const_iterator position); iterator erase(const_iterator first, const_iterator last);-4- Effects: An erase in the middle of the deque invalidates all the iterators and references to elements of the deque and the past-the-end iterator. An erase at either end of the deque invalidates only the iterators and the references to the erased elements, except that erasing at the end also invalidates the past-the-end iterator.