c++ - 从不将涉及动态内存分配的函数注释为 noexcept？

Question

假设您有一个通常永远不会失败的函数，例如:

std::string convert_integer_to_string(int x);

原则上，这将是 noexcept 的候选者。但是，实现很可能涉及动态内存管理，因此它总是会抛出 std::bad_alloc。使用 new 运算符分配内存时。

是否建议将函数注释为noexcept？

从实际的角度来看，以合理的方式处理内存不足的情况是极其困难的。大多数程序只是假设有足够的可用内存。调用 std::terminate，就像如果 noexcept 函数抛出 std::bad_alloc 时会发生的那样，在这种情况下似乎是合理的。

对我来说，noexcept 是某种形式的文档。这是一个 promise ，您(或优化器)可以安全地假设此函数永远不会抛出异常。如果您正在编写一个不关心内存不足情况的应用程序，它仍然是一个有效的假设。

我想最安全的建议是如果可能抛出 std::bad_alloc 异常，则永远不要使用 noexcept。另一方面，我想知道无论如何使用 noexcept 是否有优势，假设您不关心内存不足的情况(即，如果 std::terminate 可以)。

Answer 1

如果函数可以出于任何原因抛出异常，即使它是 std::bad_alloc ，您应该不将其声明为 noexcept .真正不能抛出异常并且实际上也很重要的函数相对较少。初级需要noexcept功能是允许在异常情况下检测可用的错误恢复选项:例如，std::vector<T, A>假设移动构造不会抛出，则可以在插入对象时使用移动构造。如果 move 构造可以抛出，则在实现强异常安全操作时，移动对象不能用于异常恢复。因此，如果类型 T 的移动构造可能失败std::vector<T, A> 的实例化不能移动对象，但需要复制它们。

特别是不要使用noexcept作为虚假文档:如果函数实际上可以抛出，则违反契约(Contract)。系统在发生这种违规行为时会以某种程度的已定义行为使用react这一事实并不意味着您应该利用它。 ...虽然简单的程序可能不会恢复并且在内存不足时死掉，但真正的程序可能至少需要存储足够的状态来恢复它们死后留下的困惑，即，这对任何功能来说都是 Not Acceptable 做出终止程序的决定(当然，除非记录了该函数的意图)。