问题标签 [noexcept]

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

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

   必须考虑是否需要在每个noexcept函数声明后附加会大大降低程序员的工作效率（坦率地说，这会让人头疼）。在哪些情况下我应该更加小心使用，在哪些情况下我可以摆脱暗示？noexceptnoexcept(false)

2. 使用后我什么时候可以真正期望观察到性能改进noexcept？特别是，给出一个代码示例，C++ 编译器在添加noexcept.

   就我个人而言，我关心的是noexcept因为为编译器提供了更大的自由度，以安全地应用某些类型的优化。现代编译器是否noexcept以这种方式利用？如果没有，我可以期待他们中的一些人在不久的将来这样做吗？

我在处理 noexcept 时遇到了一些麻烦。

这只是一个简单的函数，但你看它是如何只在 idx <= 0 时抛出异常的，我不明白。所以在我的规范中，noexcept(idx > 0)，我试图告诉编译器这个函数只有在 idx > 0 时才抛出异常。我这样做对吗？

任何帮助表示赞赏，我希望我解释正确。只是一些简单的解释会很棒。

inline当 C++11调用使用noexcept限定符声明的其他函数时，它们是否对函数或方法提供任何保证？

noexcept我假设优化编译器可以根据资格自由实现内联方法，而无需完全 EH 和堆栈展开。我也希望这是一个简单的访问器方法：

虽然这个例子看起来微不足道，但当用于实现其他类或函数时，异常保证很重要。问： C++11 标准是否解决了这个问题，还是应该标记内联方法noexcept？noexcept或者除非需要匹配类或函数规范，否则最好省略？

编辑：为了避免一些混淆：noexcept内联方法是隐式的吗？

throw()除了在运行时和noexcept编译时分别检查之外，还有什么区别吗？

这篇 Wikipedia C++11 文章建议弃用 C++03 抛出说明符。
为什么这样，noexcept有足够的能力在编译时涵盖所有这些？

[注意：我检查了这个问题和这篇文章，但无法确定弃用的充分理由。]

我编写了以下代码来测试noexcept跨函数调用的传播，它似乎不像我想象的那样工作。在 GCC 4.7.2 中，可以有效地测试一个函数是否noexcept只被直接或作为模板特化参数传递；但在作为参数传递给模板化函数或作为指向普通函数的函数指针时不会——即使该函数将其形式参数声明为 is noexcept。这是代码：

这是输出：

为什么noexceptness 在其他情况下不传播？在 的情况下test1，整个函数都用正确的类型“实例化” F，编译器当时肯定知道 F 是否是一个noexcept函数。test3当noexceptness声明被完全忽略时，为什么可以像我写的那样写？

标准是否必须对此进行具体说明？

我正在尝试编写异常安全代码。我发现使用 C++11 的 noexcept 说明符使这个目标更容易实现。

当然，一般的想法是，一个函数应该被标记为“noexcept”，当且仅当它调用的所有函数也被标记为“noexcept”。

问题在于，在大型代码库中，来自不同人的补丁经常合并在一起，很难确保保持这种一致性。

因此，我希望能够运行静态分析，该分析可以列出标记为“nothrow”的函数调用未标记为“nothrow”的函数的所有位置。

据我在手册页中看到的，GCC 无法帮助我。有没有可以帮助我的独立工具？或者也许是其他一些编译器？

采取以下代码片段：

在 clang svn 下，它编译得很好。但是，对于 gcc 4.7.2，断言失败。哪一个是正确的？（如果 gcc 是正确的，为什么？）

我已经阅读了关于 noexcept 说明符和编译器优化的不清楚的内容。指定noexcept编译器时可能会优化：

• 编译时间（更快的编译）。
• 执行时间（代码运行速度更快）。
• 或两者？
• 还是没有？

I am a little bit confused with destructors and noexcept. My understanding was that in C++11 any destructor, including user-defined, is implicitly noexcept(true), even if we throw from it. And one has to specify explicitly noexcept(false) if they want it to be that way for some reason.

I'm seeing quite the opposite - with GCC 4.7.2, the user-defined destructor, no matter how primitive the class and destructor are, is implicitly noexcept(false). What am I missing here? Is there some hidden gotcha with user-defined destructors?

我在以下测试代码段上进行了测试gcc 4.7.2：

我得到以下编译输出：

所以我的问题是：它是 C++11 规范的一部分，能够拆分constexpr函数的定义和声明，还是这是一个gcc错误？