我什么时候应该真正使用noexcept？

该noexcept关键字可以适当地应用于许多功能签名，但我不能确定何时我应该考虑在实践中使用它。根据我到目前为止所读的内容，最后一刻添加noexcept似乎解决了移动构造函数抛出时出现的一些重要问题。但是，对于一些实际的问题，我仍然无法提供满意的答案，这些问题使我不得不首先阅读更多内容noexcept。

1. 我知道有很多函数永远不会抛出的示例，但是编译器无法自行确定。noexcept在所有这种情况下，我都应该在函数声明后附加吗？

   必须考虑noexcept在每个函数声明之后是否都需要追加操作，这将大大降低程序员的工作效率（坦率地说，这将是一件痛苦的事情）。在哪些情况下我应该更小心使用它noexcept，在哪些情况下我可以摆脱隐含的含义noexcept(false)？

2. 使用后，我什么时候才能实际观察到性能改善noexcept？特别是，给出一个示例代码，在添加之后C ++编译器能够为其生成更好的机器代码noexcept。

   我个人很在乎，noexcept因为为编译器提供了增加的自由度，可以安全地应用某些优化。现代编译器是否noexcept以此方式利用？如果没有，我可以指望其中的一些在不久的将来这样做吗？

我认为对此给出“最佳实践”答案还为时过早，因为没有足够的时间在实践中使用它。如果在问题出现后立即问有关抛出说明符的问题，那么答案将与现在大不相同。

必须考虑noexcept在每个函数声明之后是否都需要追加操作，这将大大降低程序员的工作效率（坦率地说，这很痛苦）。

好吧，然后在明显无法使用该函数的情况下使用它。

使用后，我什么时候才能实际观察到性能改善noexcept？我个人很在乎，noexcept因为为编译器提供了增加的自由度，可以安全地应用某些优化。

似乎最大的优化收益来自用户优化，而不是编译器，这是因为它可能会检查noexcept和重载。大多数编译器都遵循“不罚则不抛出”的异常处理方法，因此我怀疑它会在代码的机器代码级别上改变很多（或任何东西），尽管可能通过删除处理代码。

使用noexcept在四大（构造函数，赋值，析构函数不是因为他们已经noexcept）很可能会造成最好的改进如noexcept支票模板代码中“普通”，如std容器。例如，std::vector除非被标记noexcept（否则编译器可以推断出它），否则将不会使用您的类的移动。

正如我最近一直在重复的那样：语义优先。

首先添加noexcept，noexcept(true)并且noexcept(false)最重要的是语义。它只是附带条件了许多可能的优化。

作为程序员阅读代码，的出现noexcept类似于的出现const：它帮助我更好地了解可能发生或可能发生的事情。因此，值得花一些时间考虑是否知道该函数是否将抛出。提醒一下，任何类型的动态内存分配都可能抛出。

好的，现在继续可能的优化。

最明显的优化实际上是在库中执行的。C ++ 11提供了许多特征，这些特征允许知道某个函数是否存在noexcept，并且标准库实现本身将使用这些特征来支持对其noexcept操作的用户定义对象的操作（如果可能）。如移动语义。

编译器可能仅从异常处理数据中减少了一些麻烦（也许），因为它必须考虑到您可能撒谎的事实。如果标记的函数noexcept确实抛出，则将std::terminate被调用。

选择这些语义有两个原因：

• noexcept即使依赖项尚未使用它，也会立即受益（向后兼容）
• 允许规范noexcept何时调用可能在理论上抛出但对于给定参数不期望的函数

实际上，这确实对编译器中的优化程序产生了（可能）巨大的影响。多年来，编译器实际上已经通过在函数定义以及适当的扩展之后使用空throw（）语句来具有此功能。我可以向您保证，现代编译器确实会利用这些知识来生成更好的代码。

编译器中几乎所有的优化都使用一种称为函数的“流程图”的方法来推理合法的东西。流程图由函数的通常所谓的“块”（具有单个入口和单个出口的代码区域）和块之间的边缘组成，以指示流可以跳转到何处。Noexcept更改流程图。

您要求一个具体的例子。考虑以下代码：

void foo(int x) {
    try {
        bar();
        x = 5;
        // Other stuff which doesn't modify x, but might throw
    } catch(...) {
        // Don't modify x
    }

    baz(x); // Or other statement using x
}

如果bar标记了此函数的流程图，则该流程图是不同的noexcept（没有执行方法可以在end bar和catch语句之间跳转）。当标记为时noexcept，编译器确定在baz函数期间x的值为5-据说x = 5块“支配”了baz（x）块，而没有bar()catch语句的边缘。

然后，它可以执行称为“恒定传播”的操作以生成更有效的代码。在这里，如果内联baz，则使用x的语句也可能包含常量，然后可以将以前是运行时评估的内容转换为编译时评估等。

总之，答案很简单：noexcept让编译器生成更紧密的流程图，该流程图用于推理各种常见的编译器优化。对于编译器来说，这种性质的用户注释很棒。编译器会尝试找出这些东西，但是通常不会（问题函数可能在另一个目标文件中，编译器不可见，或者可以过渡地使用某些不可见的函数），或者当它出现时，您可能根本没有意识到的一些琐碎的异常，因此它无法隐式地将其标记为noexcept（例如，分配内存可能会抛出bad_alloc）。

noexcept可以大大提高某些操作的性能。这不会在编译器生成机器代码的级别上发生，而是通过选择最有效的算法来实现：如其他提到的那样，您可以使用function进行选择std::move_if_noexcept。例如，的增长std::vector（例如，当我们致电时reserve）必须提供强大的异常安全保证。如果知道T的move构造函数没有抛出，它就可以移动每个元素。否则，它必须复制所有Ts。这已经在这篇文章中详细描述了。

除了观察使用后的性能改进外，我什么时候可以现实地使用noexcept？特别是，给出一个示例代码，在添加noexcept之后，C ++编译器能够为其生成更好的机器代码。

嗯，从来没有？从来没有时间？决不。

noexcept用于编译器性能优化，其方式与const用于编译器性能优化的方式相同。也就是说，几乎永远不会。

noexcept主要用于允许“您”在编译时检测函数是否可以引发异常。请记住：大多数编译器不会发出特殊的异常代码，除非它实际上抛出了异常。因此noexcept，向编译器提供有关如何优化函数的提示，而不仅仅是向您提供有关如何使用函数的提示，都无济于事。

像这样的模板move_if_noexcept将检测move构造函数是否使用定义，如果不是，noexcept则将返回a const&而不是&&类型的a 。如果这样做很安全，那是一种动议的方式。

通常，您应该noexcept在认为这样做确实有用的情况下使用。如果is_nothrow_constructible该类型为true，则某些代码将采用不同的路径。如果您使用的代码可以做到这一点，那么noexcept适合适当的构造函数。

简而言之：将其用于move构造函数和类似的构造，但不必觉得必须为此而烦恼。

用Bjarne的话说（The C ++ Programming Language，第4版，第366页）：

在终止是可以接受的响应的情况下，未捕获的异常将实现该目标，因为它变成了对terate（）的调用（第1.3.5.2.5节）。而且，noexcept说明符（第1.3.5.1.1节）可以使该愿望变得明确。

成功的容错系统是多层的。每个级别都尽可能地处理尽可能多的错误，而不会变得太扭曲​​，而将其他级别留给更高级别。例外支持该视图。此外， terminate()如果异常处理机制本身已损坏或使用不完全，从而未捕获异常，则通过提供转义来支持该观点。同样， noexcept为尝试恢复似乎不可行的错误提供简单的转义。

double compute(double x) noexcept;     {
    string s = "Courtney and Anya";
    vector<double> tmp(10);
    // ...
}

向量构造函数可能无法为其十个双打获取内存并抛出std::bad_alloc。在这种情况下，程序将终止。它通过调用而无条件终止std::terminate()（第30.4.1.3节）。它不会从调用函数中调用析构函数。是否调用从throw和之间的作用域的析构函数noexcept（例如，compute（）中的s）由实现定义 。该程序即将终止，因此我们无论如何都不应依赖任何对象。通过添加一个noexcept说明符，我们表明我们的代码不是为了应付抛出而编写的。

1. 我知道有很多函数永远不会抛出的示例，但是编译器无法自行确定。在所有这种情况下，我都应该在函数声明中附加noexcept吗？

noexcept这很棘手，因为它是功能接口的一部分。尤其是，如果您正在编写库，则客户端代码可以取决于noexcept属性。以后很难更改它，因为您可能会破坏现有代码。当您实现仅由应用程序使用的代码时，可能不必担心。

如果您有一个无法抛出的函数，请问自己是希望留下noexcept还是会限制将来的实现？例如，您可能想通过抛出异常来引入对非法参数的错误检查（例如，用于单元测试），或者您可能依赖于可能更改其异常规范的其他库代码。在那种情况下，保守和省略是比较安全的noexcept。

另一方面，如果您确信该函数永远不会抛出并且它是规范的一部分是正确的，则应该声明它noexcept。但是，请记住，编译器将无法检测到noexcept您的实现是否发生更改的情况。

2. 在哪些情况下应更谨慎地使用noexcept，对于哪种情况我可以摆脱隐含的noexcept（false）？

您应该专注于四类功能，因为它们可能会产生最大的影响：

1. 移动操作（移动赋值运算符和移动构造函数）
2. 调换操作
3. 内存解除分配器（运算符删除，运算符delete []）
4. 析构函数（尽管noexcept(true)除非隐式创建，否则它们是隐式的noexcept(false)）

这些函数通常应为noexcept，并且库实现很可能可以利用该noexcept属性。例如，std::vector可以在不牺牲强大的异常保证的情况下使用非投掷移动操作。否则，它将不得不退回到复制元素（就像在C ++ 98中一样）。

这种优化在算法级别上，不依赖于编译器优化。这可能会产生重大影响，尤其是在复制元素昂贵的情况下。

3. 使用noexcept之后，我何时可以实际期望获得性能改善？特别是，给出一个示例代码，在添加noexcept之后，C ++编译器能够为其生成更好的机器代码。

noexcept反对没有异常规范的好处throw()是，或在栈展开时，该标准允许编译器具有更大的自由度。即使在这种throw()情况下，编译器也必须完全解开堆栈（并且必须按照与对象构造完全相反的顺序进行操作）。

noexcept另一方面，在这种情况下，不需要这样做。不要求必须解开堆栈（但仍然允许编译器执行此操作）。这种自由度允许进一步的代码优化，因为它降低了始终能够展开堆栈的开销。

有关noexcept，堆栈展开和性能的相关问题，将在需要堆栈展开时提供有关开销的更多详细信息。

我还建议斯科特·迈耶斯（Scott Meyers）着书“有效的现代C ++”，“第14项：声明函数，除非它们不会发出异常”，以供进一步阅读。

我知道有很多函数永远不会抛出的示例，但是编译器无法自行确定。在所有这种情况下，我都应该在函数声明中附加noexcept吗？

当您说“我知道他们永远不会抛出”时，您的意思是通过检查该函数的实现，您知道该函数不会抛出。我认为这种方法是彻底的。

最好考虑一个函数是否可能抛出异常以作为该函数设计的一部分：与参数列表同等重要，并且一个方法是否是一个变量（... const）。声明“此函数永不抛出异常”是对实现的约束。省略它并不意味着该函数可能会引发异常。这意味着该函数的当前版本以及所有将来的版本都可能引发异常。这是一个约束，使实施更加困难。但是某些方法必须具有一定的约束条件才能实用。最重要的是，因此可以从析构函数中调用它们，也可以在提供强大异常保证的方法中实现“回滚”代码。