什么时候应该显式地赋予noexcept属性？

如何解决什么时候应该显式地赋予noexcept属性？

何时应该将noexcept属性添加到函数中？即编译器什么时候不能告诉函数抛出？应该对所有内容都进行标记或有办法告诉他们吗？

我不喜欢过早的优化，也不喜欢过早的归因。我不知道一种与优化时性能描述相同的“ noexcept”需求描述方法。

在需要评估的地方，请评论最常用的编译器，例如MSVC，GCC等。

解决方法

C++ Core Guidelines建议基本上在代码不会抛出的所有地方使用它。这对于库来说最重要，因为代码检查器会使用您调用的函数来查看其是否为noexcept，否则会收到一连串的警告。

也就是说，最重要的建议是制作swap，move和析构函数noexcept。

C ++核心准则还建议使用默认构造函数noexcept，这通常很棒，但是许多模式（例如pImpl idiom）通常会在其默认构造函数中分配内存。因此，我通常在默认构造函数（或仅采用默认参数的构造函数）上使用noexcept，但是如果我知道它可以抛出，我会明确标记为nothrow(false)。

如果将默认构造函数，复制构造函数，赋值运算符，move构造函数，move运算符或析构函数声明为=default，则其隐式为noexcept。所有析构函数也都是隐式noexcept。

有一个概念，您可以标记noexcept来表示“如果它确实抛出了，那就继续崩溃”。我发现这个概念有些笨拙，因此在我的代码中我标记了可以抛出noexcept(false)或未指定的事物。通常是调用new或初始化std容器的东西。

,

何时应该将noexcept属性添加到函数中？

每当您要记录和执行函数永不抛出时。

重要的是要记住，这里的错误意味着将调用std::terminate()而不是传播异常。因此，这可能是一种悲观。

即编译器什么时候不能够告诉函数抛出？

相反：编译器必须假设所有抛出的异常，除非可以证明（否则）。

当它具有必需的定义时，将可以证明它。例如，在没有LTO的TU之间，它不会。

我不知道如何“描述” noexcept的需求

就像在其他情况下一样：无论有无，都可以测量。

对于大多数项目来说，启用LTO是更好的应对方法。