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: 184.108.40.206 [deque.modifiers] Status: CD1 Submitter: Steve LoBasso Opened: 2007-02-17 Last modified: 2016-02-10
Priority: Not Prioritized
View all other issues in [deque.modifiers].
View all issues with CD1 status.
The standard states at 220.127.116.11 [deque.modifiers]/4:
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.
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.
Change 18.104.22.168 [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 . An erase at either end of the deque invalidates only the iterators and the references to the erased elements.