stackoverflow.com上最受欢迎的C++帖子《迭代器失效规则》称，不清楚past-the-end迭代器（即通过end()、cend()、rend()和crend()返回的迭代器）是否按照指向容器元素的普通迭代器相同的规则失效。这些声明适用于2003年和2011年的C++，它们推迟到一个讨论《末位迭代器失效规则》的帖子，在该帖子中，被采纳的答案表明2003标准在此问题上存在歧义。这个结论是基于23.1/10的一条评论（在swap()的上下文中），似乎暗示当规范没有明确提到past-the-end迭代器的失效时，它们可能会失效。
该帖子的一个问题评论（由mike-seymour发表）表明，在deque的情况下，C++11对此事是明确的。我的问题是关于所有容器的：
换句话说，
std :: vector或std :: string 插入数据）。
换句话说，
我可以信任在执行不建议使过期的迭代器失效的容器操作后，过期的迭代器的有效性吗？
您可以像其他迭代器一样信任过期的迭代器：不会（潜在地）使迭代器失效的任何操作都不会使它们失效。除了标准存在错误的可能性外，在没有明确表示可能会使其失效的操作中，它们将保持有效。reserve代码，你认为这明显是标准中的缺陷吗？ - Mark B另外还可以查看使用 std::set 的 end() 的测试 - https://godbolt.org/z/5ecdqYod3。特别需要提到的是指向尾后元素的迭代器。一般来说，这个迭代器在失效时会像指向未删除元素的普通迭代器一样失效。因此 std::set::end 从不失效，std::unordered_set::end 仅在重新哈希时失效，std::vector::end 总是失效（因为它总是在修改后的元素之后），等等。
有一个例外情况：删除 std::deque 的最后一个元素的删除操作会使得指向尾后元素的迭代器失效，即使它不是容器的已删除元素（或根本不是元素）。结合 std::deque 迭代器的一般规则，其净结果是，唯一不会使 std::deque::end 失效的修改操作是删除第一个元素而不是最后一个元素。
至少在GCC中，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
}
.rend()返回一个迭代器适配器，具体来说是适配a.begin()而不是a.end()，因此没有矛盾。根据定义，rend()适配begin()，而该迭代器已被明确地erase使其无效。 - sehe
vector::erase会“使在删除点或之后位置的迭代器和引用失效”。尾迭代器必然“位于删除点之后”。 - James McNellisvector::reserve()怎么样呢？23.3.6.3/5（我有修订版n3337）：“重新分配使指向序列中的元素的所有迭代器失效”，而此列表不包括过去的结束迭代器，根据定义，它们不指向序列中的元素。然而，SGI实现使所有迭代器无效，可能也包括过去的结束迭代器 [http://www.sgi.com/tech/stl/Vector.html#5]。更多信息：https://dev59.com/lXI-5IYBdhLWcg3w483k#1624961 - nknight