noexcept can dramatically improve performance of some operations. This does not happen at the level of generating machine code by the compiler, but by selecting the most effective algorithm: as others mentioned, you do this selection using function std::move_if_noexcept. For instance, the growth of std::vector (e.g., when we call reserve) must provide a strong exception-safety guarantee. If it knows that T's move constructor doesn't throw, it can just move every element. Otherwise it must copy all Ts. This has been described in detail in this post.

我认为现在给出一个“最佳实践”的答案还为时过早，因为还没有足够的时间在实践中使用它。如果在抛出说明符刚出来的时候被问到这个问题，那么答案将与现在大不相同。

不得不考虑是否需要在每个函数声明后添加noexcept将大大降低程序员的工作效率(坦率地说，这将是一种痛苦)。

那么，当函数明显不会抛出时使用它。

在使用noexcept之后，我什么时候才能真正看到性能的改善?[…就我个人而言，我不关心什么，因为给编译器提供了更多的自由，可以安全地应用某些类型的优化。

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

在四大函数中使用noexcept(构造函数，赋值函数，而不是析构函数，因为它们已经是noexcept了)可能会带来最好的改进，因为noexcept检查在模板代码中是“常见的”，比如在std容器中。例如，std::vector不会使用类的move，除非它标记为noexcept(或者编译器可以以其他方式推断它)。

正如我这些天一直在重复的:语义第一。

添加noexcept、noexcept(true)和noexcept(false)首先是关于语义的。它只是附带地限制了一些可能的优化。

作为一个阅读代码的程序员，noexcept的存在类似于const:它帮助我更好地理解什么可能发生，什么可能不发生。因此，花些时间考虑是否知道函数是否会抛出是值得的。提醒一下，任何类型的动态内存分配都可能抛出。

现在来看可能的优化。

最明显的优化实际上是在库中执行的。c++ 11提供了许多特性，允许知道函数是否为noexcept，如果可能的话，标准库实现本身将使用这些特性来支持它们所操作的用户定义对象上的noexcept操作。比如move语义。

编译器可能只从异常处理数据中删减了一些内容，因为它必须考虑到您可能说谎的事实。如果标记为noexcept的函数抛出异常，则调用std::terminate。

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

立即受益于noexcept，即使依赖还没有使用它(向后兼容) 允许在调用理论上可能抛出，但对于给定参数不期望抛出的函数时指定noexcept

我知道有许多函数永远不会抛出，但编译器无法自行确定。在所有这些情况下，我应该在函数声明中添加noexcept吗?

当你说“我知道[它们]永远不会抛出”时，你的意思是通过检查函数的实现，你知道函数不会抛出。我认为这种方法是由内而外的。

It is better to consider whether a function may throw exceptions to be part of the design of the function: as important as the argument list and whether a method is a mutator (... const). Declaring that "this function never throws exceptions" is a constraint on the implementation. Omitting it does not mean the function might throw exceptions; it means that the current version of the function and all future versions may throw exceptions. It is a constraint that makes the implementation harder. But some methods must have the constraint to be practically useful; most importantly, so they can be called from destructors, but also for implementation of "roll-back" code in methods that provide the strong exception guarantee.

用Bjarne的话来说(c++编程语言，第4版，第366页):

Where termination is an acceptable response, an uncaught exception will achieve that because it turns into a call of terminate() (§13.5.2.5). Also, a noexcept specifier (§13.5.1.1) can make that desire explicit. Successful fault-tolerant systems are multilevel. Each level copes with as many errors as it can without getting too contorted and leaves the rest to higher levels. Exceptions support that view. Furthermore, terminate() supports this view by providing an escape if the exception-handling mechanism itself is corrupted or if it has been incompletely used, thus leaving exceptions uncaught. Similarly, noexcept provides a simple escape for errors where trying to recover seems infeasible. double compute(double x) noexcept; { string s = "Courtney and Anya"; vector<double> tmp(10); // ... } The vector constructor may fail to acquire memory for its ten doubles and throw a std::bad_alloc. In that case, the program terminates. It terminates unconditionally by invoking std::terminate() (§30.4.1.3). It does not invoke destructors from calling functions. It is implementation-defined whether destructors from scopes between the throw and the noexcept (e.g., for s in compute()) are invoked. The program is just about to terminate, so we should not depend on any object anyway. By adding a noexcept specifier, we indicate that our code was not written to cope with a throw.

这实际上(可能)对编译器中的优化器产生了巨大的影响。实际上，编译器通过函数定义后的空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，则此函数的流图会有所不同(执行无法在bar的末尾和catch语句之间跳转)。当标记为noexcept时，编译器确定在baz函数期间x的值为5 - x=5块被认为“支配”了baz(x)块，没有从bar()到catch语句的边。

然后，它可以执行所谓的“常量传播”来生成更有效的代码。在这里，如果baz是内联的，那么使用x的语句也可能包含常量，然后过去的运行时求值可以转换为编译时求值，等等。

Anyway, the short answer: noexcept lets the compiler generate a tighter flow graph, and the flow graph is used to reason about all sorts of common compiler optimizations. To a compiler, user annotations of this nature are awesome. The compiler will try to figure this stuff out, but it usually can't (the function in question might be in another object file not visible to the compiler or transitively use some function which is not visible), or when it does, there is some trivial exception which might be thrown that you're not even aware of, so it can't implicitly label it as noexcept (allocating memory might throw bad_alloc, for example).