该noexcept关键字可以适当地应用于许多函数签名，但我不确定何时应该考虑在实践中使用它。根据我目前所读到的内容，最后一分钟的添加noexcept似乎解决了移动构造函数抛出时出现的一些重要问题。但是，对于一些导致我首先阅读更多内容的实际问题，我仍然无法提供令人满意的答案noexcept。
noexcept
必须考虑是否需要在 每个*noexcept函数声明之后附加会大大降低程序员的工作效率（坦率地说，这会让人头疼）。在哪些情况下我应该更加小心使用，在哪些情况下我可以摆脱暗示？ *noexcept``noexcept(false)
noexcept``noexcept(false)
就我个人而言，我关心的是noexcept因为为编译器提供了更大的自由度，以安全地应用某些类型的优化。现代编译器是否noexcept以这种方式利用？如果没有，我可以期待他们中的一些人在不久的将来这样做吗？
我认为现在给出“最佳实践”答案还为时过早，因为没有足够的时间在实践中使用它。如果在抛出说明符出现后立即询问这个问题，那么答案将与现在大不相同。
必须考虑是否需要noexcept在每个函数声明后附加会大大降低程序员的工作效率（坦率地说，这会很痛苦）。
好吧，然后在很明显该函数永远不会抛出时使用它。
使用后我什么时候可以真正期望观察到性能改进noexcept？[…] 就我个人而言，我很在意，noexcept因为它为编译器提供了更大的自由度，可以安全地应用某些类型的优化。
似乎最大的优化收益来自用户优化，而不是编译器优化，因为有可能对其进行检查noexcept和重载。大多数编译器都遵循一个 no-penalty-if- you-don’t-throw 异常处理方法，所以我怀疑它会在代码的机器代码级别上改变很多（或任何东西），尽管可能会通过删除来减少二进制大小处理代码。
noexcept在四大（构造函数、赋值，而不是它们已经存在的析构函数）中使用noexcept可能会带来最好的改进，因为noexcept检查在模板代码（例如std容器）中是“常见的”。例如，除非它被标记（或者编译器可以以其他方式推断它），否则std::vector不会使用你的类的移动。noexcept
std
std::vector
