使用std::set键的引用擦除自身是否存在安全问题？

先看第一段开发中很常见的写法：

std::set<int> int_set = {1, 2, 3, 4};

for(const auto& key : int_set)
{
    if(key == 2)
    {
        int_set.erase(key);
        break;
    }
}

这段代码运行结果完全符合预期，但很多开发者会直觉觉得这种写法有隐患：按照STL容器的通用失效规则，erase操作执行完成后，被擦除元素对应的引用、迭代器都会直接失效，拿着指向待删除元素本身的引用调用erase，似乎属于未定义行为。

另一段逻辑本质相同、会引发同样疑问的代码片段如下：

std::set<int> int_set = {1, 2, 3, 4};
const auto& key  = *int_set.find(2);
int_set.erase(key);

结论：上述两段代码在标准C++规范下是安全的，不存在未定义行为 #

核心原因有两个：

• 这两处调用的都是std::set接收const value_type&参数的erase重载，这个版本的erase逻辑是先在容器内查找和传入值匹配的元素，定位到节点后再执行销毁、内存释放操作。传入的元素引用仅在函数调用初期用于匹配键值，不会被用来直接定位要删除的节点，根本不需要保证引用在擦除动作完成后依然有效。只要调用erase的瞬间，传入的引用是合法有效的——上面两个场景都满足这个条件：调用erase时元素还未被删除，绑定到元素的引用自然合法——整个执行流程就不会出问题。
• 第一段循环代码里，erase执行完立刻用break跳出了循环，不会触发范围for内部的下一轮迭代逻辑，完全碰不到被删除元素对应的失效迭代器，自然也不会出现迭代器失效引发的未定义行为。

容易混淆的风险场景 #

要注意不要把这种写法和两类错误写法搞混：

• 调用传入迭代器的erase重载时，必须保证传入的迭代器是合法、指向容器内现存元素的，否则会直接触发未定义行为，这也是很多人觉得“拿元素本身删元素不安全”的印象来源——这个规则是针对迭代器入参的，不适用于值/常量引用入参的erase重载。
• 如果在循环中执行erase之后没有立刻break，继续跑范围for的后续迭代，会因为被删元素的迭代器已经失效，在范围for内部自动做迭代器自增的时候触发未定义行为，这种写法才是真的有问题。

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