为何unordered_map的存在会影响拷贝/移动构造函数的选择？

我来帮你拆解这个C++里容易踩的坑！先把问题场景、修复方案和根源理清楚：

问题场景还原 #

你遇到的情况是这样的：

• 自定义类Foo包含SubFoo类型成员和unique_ptr，依赖编译器生成的默认拷贝/移动构造来处理unique_ptr的所有权转移
• 初始状态下（SubFoo没有unordered_map成员），vector<Foo>扩容时会正常调用默认移动构造，unique_ptr所有权顺利转移，程序运行无问题
• 但给SubFoo添加unordered_map成员后，vector扩容时突然放弃移动构造，转而调用拷贝构造，直接导致unique_ptr双重释放，触发断言失败

已验证的修复方案 #

你找到的两种方案都是有效的，本质都是让Foo的移动构造满足vector扩容的异常安全要求：

• 给SubFoo显式声明默认移动构造：SubFoo(SubFoo&&) = default;
• 给Foo添加自定义移动构造函数（逻辑和默认生成的一致，但必须显式标注noexcept）

问题根源拆解 #

这一切的核心在于两个C++规则的叠加：

1. 默认移动构造的noexcept推导规则 #

编译器生成的默认移动构造函数，其noexcept属性是由类的所有非静态成员的移动构造共同决定的：只有当所有成员的移动构造都是noexcept(true)时，默认移动构造才会被标记为noexcept(true)；只要有一个成员的移动构造是noexcept(false)，默认移动构造就会是noexcept(false)。

当SubFoo添加了unordered_map后，问题就出在这里：不同编译器/标准版本下，unordered_map的移动构造noexcept属性可能不同。比如在C++17之前，标准并没有强制要求标准库容器的移动构造必须是noexcept，部分编译器实现的unordered_map移动构造是noexcept(false)的——这直接导致SubFoo的默认移动构造变成noexcept(false)，进而让Foo的默认移动构造也变成noexcept(false)。

2. vector扩容的异常安全策略 #

vector扩容时，会优先选择移动构造来转移现有元素，但有个前提：移动构造必须是noexcept(true)。这是因为如果移动过程中抛出异常，vector无法保证原元素的完整性（部分元素已经被移动，部分还没），无法回滚到扩容前的状态；而拷贝构造可以保证异常安全——如果拷贝失败，原元素依然完好。

所以当Foo的默认移动构造变成noexcept(false)后，vector为了保证异常安全，就会 fallback 到拷贝构造，而Foo里的unique_ptr是不可拷贝的（编译器生成的拷贝构造会尝试拷贝unique_ptr，这在运行时会触发断言失败）。

你的疑问解答 #

疑问1：为什么编译器没警告默认移动构造不可用？ #

其实默认移动构造并没有“不可用”，它依然存在，只是noexcept属性从true变成了false。编译器默认不会针对这种noexcept属性的变化发出警告，因为移动构造本身还是可以被调用的——只是vector出于异常安全的考虑选择不用它而已。

如果想要看到这类警告，可以开启编译器的严格警告选项，比如GCC的-Wnoexcept，或者Clang的-Wexceptions相关选项。

疑问2：不同编译器对默认移动构造的noexcept声明分歧，和vector扩容有关吗？ #

完全相关！这就是为什么两个修复方案在不同编译器下有不同的noexcept要求：

• 对于SubFoo的修复：在你测试的GCC版本中，unordered_map的移动构造被实现为noexcept(true)，所以当你显式默认SubFoo的移动构造时，它的noexcept属性是true，进而让Foo的默认移动构造也变成noexcept(true)，vector就会优先使用移动构造。
• 对于Foo的自定义移动构造：自定义的移动构造函数默认是noexcept(false)的（和编译器生成的默认移动构造不同，默认生成的会自动推导noexcept属性），所以你必须显式添加noexcept，才能让vector认为它是异常安全的，进而选择它来扩容。

而Clang提示的“显式默认的移动构造异常说明与计算的不匹配”，是因为你显式指定了noexcept，但编译器根据成员推导出来的实际noexcept属性和你写的不一致——比如你写了noexcept(true)，但某个成员的移动构造是noexcept(false)，这时候编译器就会发出警告。

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