存储shared_ptr的vector删除元素时内存损坏问题原因求解

你最初的实现出现问题和std::shared_ptr的引用计数逻辑无关，完全是删除逻辑的索引匹配错误导致的内存越界访问，具体问题如下：

• 你选择的是先遍历全量元素，收集所有待删除元素的原始索引，再批量按索引删除的逻辑，但你用的尾元素替换+pop_back()的删除方式，每执行一次删除操作，vector的实际长度就会减1，且末尾的元素位置会发生变化。你收集的是删除操作执行前的旧索引，执行第一次删除后，后面所有旧索引指向的实际元素已经完全不对，甚至会超出vector的实际长度触发越界。

举个实际场景示例：

假设当前offers长度为5，遍历后收集到的待删除索引是[2, 4]

1. 第一次处理索引2：将索引4的元素赋值到索引2的位置，执行pop_back()后vector长度变为4，此时原来的索引4已经不再属于vector的合法访问范围
2. 第二次处理旧索引4：直接访问vector的第5个元素，触发越界，读写的都是栈上的垃圾内存，自然会出现元素损坏、指针指向无效数据的问题

• 另一种逻辑错误场景：如果收集到的待删除索引是[1, 2]，第一次处理索引1时，原本索引2位置的元素会被尾元素覆盖，你第二次处理旧索引2时，删掉的根本不是你最初判定为要删除的元素，反而会误删合法元素。
• 问题偶发的原因：只有当待删除索引数量≥2，且后处理的旧索引超出删除后的vector长度，或待删除索引连续时，才会触发明显的异常，不符合该条件的场景下代码看起来能正常运行，所以表现为偶发故障。

你后续改用erase-remove惯用法的实现是完全正确的，std::remove_if会在单次遍历中完成合法元素的前移，避免了索引失效的问题，执行效率和正确性都远高于你最初的实现。

内容的提问来源于stack exchange，提问作者quevivasbien