迭代器失效是指容器内部结构变化导致迭代器指向无效内存位置，引发程序崩溃或未定义行为。其核心原因是容器底层存储机制不同，操作后需重新获取或更新迭代器。1. std::vector 和 std::string 因连续内存存储，在扩容或插入删除时会导致全部或部分迭代器失效；2. std::list 和 std::forward_list 作为链表结构，仅使被操作节点的迭代器失效，其余保持有效；3. 有序关联容器如 std::map、std::set 使用红黑树，插入删除不影响其他迭代器；4. 无序关联容器如 std::unordered_map 在 rehash 时会使所有迭代器失效，插入未触发 rehash 时则保持稳定。使用时应根据容器特性合理处理迭代器更新问题。
迭代器失效，简单来说，就是你手里拿着一个指向容器里某个元素的“地址牌”，但容器内部发生了变化，导致你手里的牌子指向了错误的地方，或者指向的地方已经不存在了。这就像你在一个不断变动的房间里，根据旧的座位号去找人，结果人已经换了位置甚至离开了，你再按那个号去找，轻则找不到人，重则直接撞墙。在C++里，这通常会导致程序崩溃或者产生难以追踪的未定义行为（Undefined Behavior）。
解决方案
理解迭代器失效的核心在于容器的底层存储机制。不同的容器类型，因为其数据组织方式不同，在执行某些操作时，对迭代器的影响也截然不同。解决之道无他，唯手熟尔——熟悉每种容器的特性，并在操作后审慎处理迭代器。关键在于，当你修改容器（增、删元素）时，要假设相关的迭代器可能已经失效，并及时更新或重新获取。很多时候，避免在循环内部直接删除元素而不更新迭代器是新手常犯的错误。安全的做法通常是使用被删除元素的下一个迭代器作为循环的起点，或者在删除后立即更新当前迭代器。
std::vector 与 std::string：内存重分配的“重灾区”
说到迭代器失效，std::vector 和 std::string 这俩哥们儿绝对是排头兵。它们都是基于连续内存存储的，这意味着一旦底层数组需要扩容（比如你 push_back 了一个元素，而当前容量不够了），整个数据块就可能被移动到内存的另一个地方。
我个人觉得，vector 的这个特性，既是它的强大之处（缓存友好，随机访问快），也是它最让人头疼的地方。当你往 vector 里添加元素，尤其是当它需要重新分配内存时，所有指向这个 vector 内部元素的迭代器、指针、甚至引用，统统都会失效。想想看，你原来指向地址 A，现在整个 vector 搬到了地址 B，你手里的 A 自然就废了。
具体来说：
push_back() / emplace_back()： 当导致 vector 容量增长时（即 capacity() 发生变化），所有迭代器都会失效。如果容量足够，则只有 end() 迭代器可能失效（因为它现在指向新元素的下一个位置）。insert()： 这个操作更复杂。如果需要重新分配内存，所有迭代器都会失效。即使不需要重新分配，从插入点开始及之后的所有迭代器都会失效，因为它们后面的元素都往后挪了。erase()： 从被擦除元素的位置开始，到 end() 之间的所有迭代器都会失效。因为这些元素都往前挪了，它们的相对位置变了。被擦除的那个迭代器本身当然也失效了。clear()： 清空 vector 后，所有迭代器都失效。pop_back()： 只有 end() 迭代器失效，因为最后一个元素没了。
std::string 的行为和 std::vector 几乎一样，所以它的迭代器失效规则也完全相同。说实话，很多时候我看到一些新手代码在 vector 循环里 erase 元素，我就知道这大概率会出问题，因为迭代器更新机制没考虑进去。
std::list 与 std::forward_list：链表结构的稳定性优势
与 vector 截然不同的是 std::list 和 std::forward_list。它们是基于节点的链表结构，每个元素都是一个独立的节点，分散在内存中，通过指针连接起来。这种结构决定了它们在增删元素时，对迭代器的影响要小得多。
这有点像你在一串珠子里，你拿掉或者插入一颗珠子，并不会影响其他珠子的位置。只有你直接操作的那颗珠子本身，或者与它直接相连的指针需要调整。
insert()： 当你在 list 或 forward_list 中插入一个元素时，除了新插入的元素及其前后链接的迭代器外，其他所有指向容器中现有元素的迭代器都不会失效。因为它们所指向的节点地址没变。erase()： 只有被擦除的那个元素的迭代器会失效。其他元素的迭代器仍然有效。这是一个巨大的优势，尤其是在需要频繁删除元素的场景下。splice()： 这个操作比较特殊，它会将一个 list 中的元素“剪切”并“粘贴”到另一个 list 中。被移动的元素在源 list 中的迭代器会失效，但在目标 list 中，这些元素会获得新的有效迭代器（如果之前有的话，或者新的迭代器指向它们）。clear()： 清空容器后，所有迭代器失效。
所以，如果你有一个场景，需要频繁地在中间位置插入或删除元素，并且希望迭代器保持稳定，那么 std::list 往往是比 std::vector 更安全、更合适的选择。当然，代价就是随机访问性能差，缓存不友好。
std::map、std::set 及其他关联容器：树与哈希的考量
关联容器分为有序（如 std::map、std::set、std::multimap、std::multiset）和无序（如 std::unordered_map、std::unordered_set、std::unordered_multimap、std::unordered_multiset）。它们的迭代器失效行为也有显著差异。
有序关联容器（std::map、std::set 等）：这些容器通常基于红黑树实现。树的节点也是独立分配的，类似于链表。
insert()： 插入一个新节点并不会改变其他节点的内存地址。因此，所有指向现有元素的迭代器都不会失效。erase()： 只有被擦除的那个元素的迭代器会失效。其他元素的迭代器保持有效。这使得有序关联容器在迭代器稳定性方面表现优秀，与 list 类似。
无序关联容器（std::unordered_map、std::unordered_set 等）：这些容器基于哈希表实现，内部通常包含一个桶数组和链表（或红黑树）来处理哈希冲突。
insert()： 这是最需要注意的地方。当插入元素导致哈希表的“负载因子”（load_factor）超过预设阈值时，容器会进行“rehash”操作。rehash 意味着整个哈希表的底层数组会被重新创建，所有元素会被重新散列到新的桶中。这和 vector 的重新分配非常相似，会导致所有迭代器失效。如果插入没有引起 rehash，那么迭代器就不会失效。erase()： 只有被擦除的那个元素的迭代器会失效。其他元素的迭代器不受影响（除非该删除操作间接触发了某些内部优化，但通常不会）。rehash() / reserve()： 显式调用这些方法，强制容器重新构建哈希表，都会导致所有迭代器失效。
所以，在 unordered 容器中，插入操作的迭代器稳定性是不确定的，取决于是否发生 rehash。如果对迭代器稳定性有严格要求，且插入操作频繁，要么选择有序容器，要么需要在使用 unordered 容器时特别注意 rehash 的可能性。我个人在处理 unordered_map 时，如果需要在循环中插入或删除，会非常小心，有时甚至会选择先收集需要操作的键，然后在循环外进行批量操作，以避免迭代器失效带来的麻烦。
以上就是iterator失效有哪些情况 不同容器操作导致的迭代器失效分析的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1468486.html
微信扫一扫 
支付宝扫一扫 
