c++ - 为什么动态检查 C++0x 的 `noexcept`？

Question

我很好奇 C++0x FCD 中 noexcept 背后的基本原理. throw(X) 已被弃用，但 noexcept 似乎做同样的事情。编译时没有检查 noexcept 是否有原因？如果这些函数被静态检查，它们只在 try block 中调用抛出函数，似乎会更好。

Answer 1

基本上，这是一个链接器问题，标准委员会不愿破坏 ABI。 (如果由我决定，我会这样做，它真正需要的只是重新编译库，我们已经有了线程启用的这种情况，而且它是可管理的。)

考虑它会如何运作。假设要求是

1. 每个析构函数都是隐式的 noexcept(true)
   • 可以说，这应该是一个严格的要求。抛出析构函数总是是一个错误。
2. 每个外部“C”都是隐含的 noexcept(true)
   • 同样的论点:C-land 中的异常总是是一个错误。
3. 所有其他函数都是隐式 noexcept(false)除非另有说明
4. 一个 noexcept(true)函数必须包装其所有 noexcept(false)来电try{}catch(...){}
   • 以此类推，const 方法不能调用非 const 方法。
5. 此属性必须在重载解析、函数指针兼容性等方面体现为不同的类型。

听起来很合理，对吧？

要实现这一点，链接器需要区分 noexcept(true)和 noexcept(false)函数的版本，就像您可以重载成员函数的 const 和 const 版本一样。

那么这对名称命名意味着什么？为了向后兼容现有的目标代码，我们要求所有现有的名称都被解释为 noexcept(false)对 noexcept(true) 进行额外修改版本。

这意味着我们无法链接到现有的析构函数，除非修改 header 以将它们标记为 noexcept(false)

• 这会破坏向后兼容性，
• 这可以说是不可能的，见第 1 点。

我亲自与一位标准委员会成员谈过此事，他说这是一个仓促的决定，主要是出于对容器中移动操作的限制(否则您可能会在 throw 后丢失元素，这违反了基本保证)。请注意，这个人的设计理念是容错代码是好的。得出你自己的结论。

就像我说的，我会破坏 ABI 而不是破坏语言。 noexcept只是对旧方式的边际改进。静态检查总是更好。