End iterator invalidation rules

Question

Regarding this question on iterator invalidation rules, it seems obvious that the spirit of the standard means, for example, that "an erase in the middle of the deque invalidates all the iterators and references to elements of the deque" also refers to the end iterator.

However, I can't find anywhere that the standard makes this explicit, and strictly speaking the end iterator is not an iterator to an element in the container.

Does the 2003 standard make this clear somewhere?

For example, 23.1/10: no `swap()` function invalidates any references, pointers, or iterators referring to the elements of the containers being swapped. [ Note: The end() iterator does not refer to any element, so it may be invalidated. —end note ] ... I do not know if we can be certain that `iterator referring to an element` has been used consistently in the Standard to exclude end iterators :/ — Matthieu M., Jun 22 '11 at 13:22
Cannot find any paragraph distinguishing end from other iterators. `end() returns an iterator which is the past-the-end value for the container`. That's all. Gee. — user703016, Jun 22 '11 at 13:28
I don't have the 2003 standard to hand, but C++0x seems to be clear on this, e.g. "An erase operation that erases the last element of a deque invalidates only *the past-the-end iterator* and all iterators and references to the erased elements." (emphasis mine). — Mike Seymour, Jun 22 '11 at 13:35
@Tomalak: n3242, 23.3.3.4 (probably not the most up-to-date draft) — Mike Seymour, Jun 22 '11 at 13:39
Program defensively. Assume the `end()` iterator is invalidated along with all the others, no matter what the fine print of the standard says. — Mark Ransom, Jun 22 '11 at 14:31
@MarkRansom: Of course. That's not what this question is about, though. — Lightness Races in Orbit, Jun 22 '11 at 14:34
@Tomalak: Which is why I made my statement a comment and not an answer. — Mark Ransom, Jun 22 '11 at 14:38
@Matthieu: Feel free to write that as an answer. I'm satisfied with it. — Lightness Races in Orbit, Jun 22 '11 at 16:20
@Tomalak but why does it have an explicit remark on the rule for "all swap() functions" for the end iterator? If it wouldn't matter why do they note it? — Johannes Schaub - litb, Jun 22 '11 at 16:40
@Johannes: I suppose if the `end` iterator points to a sentinel value within the container, then the `end` iterators after the swap won't point to the sentinel in the "right" container, thus any sequence [it, end) would be ill-formed as `end` would not be reachable from `it`. — Matthieu M., Jun 22 '11 at 18:21
@Ajay: No, please do not use code formatting for things that are not code. — Lightness Races in Orbit, Apr 13 '17 at 19:14

score 9 · Accepted Answer · answered Jun 22 '11 at 18:22

9

For example, 23.1/10:

no swap() function invalidates any references, pointers, or iterators referring to the elements of the containers being swapped. [ Note: The end() iterator does not refer to any element, so it may be invalidated. —end note ]

I do not know if we can be certain that iterator referring to an element has been used consistently in the Standard to exclude end iterators :/

As said in a comment, I suppose this is to allow end iterators pointing to sentinel values within the container.

For example, a typical doubly linked List implementation is to create a Node structure, and have one Node by value within the List to act as the end node.

answered Jun 22 '11 at 18:22

Matthieu M.

287,565
48
449
722

2

I'm satisfied, through this answer and through the relevant comments, that C++03 is ambiguous in this matter. Of course, in practice, we know that we should treat past-the-end iterators in the same manner as iterators to container elements; however, this answer is the answer to _this_ question. – Lightness Races in Orbit Jun 22 '11 at 23:27
Actually cppreference.com does talk about end() iterator's invalidation. See https://stackoverflow.com/a/72624474/199150 – Shriram V Jun 14 '22 at 23:42
Interesting; though not authoritative. I haven't followed the situation to know if requirements were tightened in newer standard versions (post C++11). – Matthieu M. Jun 15 '22 at 09:40

End iterator invalidation rules

1 Answers1

Linked