Past-the-end iterator invalidation in C++11

26
votes

The most popular post on C++ Iterator invalidation rules claims that it's not clear if the past-the-end iterators (i.e., those returned by end(), cend(), rend(), and crend()) are invalidated according to the same rules as normal iterators, which point to elements in the container. These claims, made for both 2003 and 2011 C++, defer to a post discussing End iterator invalidation rules, where the accepted answer suggests that the 2003 standard is ambiguous on the matter. This conclusion is based on a comment in 23.1/10 (in the context of swap()) that seems to imply that when the spec does not explicitly mention invalidation of past-the-end iterators, they may be invalidated.

A comment on that post's question (by mike-seymour) suggests that C++11 is unambiguous on this matter, in the case of deques. My question is about all containers:

  • In C++11, are there any container operations that may invalidate a past-the-end iterator, and where this behavior is ambiguous in the language specification?

Said differently,

  • Can I trust the validity of a past-the-end iterator after performing a container operation that does not say it may invalidate the past-the-end iterators?
3
c++iterator
You can trust the validity of past-the-end iterator after performing an operation that does not invalidate any iterator. For all other cases, I would not know, I don't really care: reobtain the iterator (which is a constant time operation) and there is no need to worry about whether that particular iterator is invalidated or not... – David Rodríguez - dribeas
There are certainly operations that may invalidate an end iterator. vector::erase, for example, "invalidates iterators and references at or after the point of erasure." The end iterator is necessarily "after the point of erasure." – James McNellis
@dribeas: Thanks for your workaround; I'm sure it's optimal in almost every situation, especially given compiler inlining, etc. There is anecdotal evidence (stackoverflow.com/q/3084109/985943) that you might get performance benefits from caching the past-the-end pointers; indeed this motivated my question. – nknight
@JamesMcNellis: Agreed. The standard is unambiguous here because the end iterator is [defined somewhere to be] after the point of erasure. How about vector::reserve(), 23.3.6.3/5 (I have rev. n3337), "Reallocation invalidates all the...iterators referring to the elements in the sequence," and this list does not include the past-the-end iterators, which by definition do not point to elements in the sequence. Yet, the SGI implementation invalidates all iterators, presumably the past-the-end ones too [sgi.com/tech/stl/Vector.html#5]. More: stackoverflow.com/a/1624961/985943 – nknight
That is assuredly a defect in the C++11 specification. – James McNellis

3 Answers

12
votes

My question is about all containers:

  • In C++11, are there any container operations that may invalidate a past-the-end iterator, and where this behavior is ambiguous in the language specification?

I am not sure what you mean with "where this behavior is ambiguous in the language specification", but there certainly are operations that invalidate past-the-end operators (like insert into a std::vector or std::string).

Said differently,

  • Can I trust the validity of a past-the-end iterator after performing a container operation that does not say it may invalidate the past-the-end iterators?

You can trust the past-the-end iterator like any other iterator: Any operation that does not (potentially) invalidate iterators won't invalidate them. Except for the possibility of the standard sporting a bug, that is all operations where it doesn't say that they (potentially) invalidate operators.

2
votes

You should be able to trust it if the standard says the operation will not invalidate iterators. Anything else should be treated as a bug in the standard library implementation.

0
votes

At least in GCC end iterator gets invalidated for std::map:

#include <set>
#include <stdlib.h>
#include <assert.h>
int main() {
  std::set<int> a;
  a.insert(1);
  std::set<int>::reverse_iterator rit(a.rbegin());
  ++rit;
  assert(rit==a.rend());
  a.erase(a.begin());
  assert(a.rend()==rit); // FAIL
}