c++ - 如果类型为 noexcept，C++ 11 STL 中的哪些算法和容器可以运行得更快？

Question

在工作中出现了关于使用 noexcept 有多少关心的争论。我们都知道 noexcept 并没有真正为编译器的优化器做很多事情，除了编译器必须假设的外部定义的代码可能会抛出，因为它不知道它的实现，所以标记事物的唯一真正的其他性能优势noexcept 用于使用 std::move_if_noexcept<> 的代码假设主要是 STL 容器及其算法。

因此评估是这样的:不使用 noexcept，除非:

1. 编译器不知道可调用的实现的外部函数和类。

2. 移动构造函数、移动赋值运算符并交换任何可能包含在 STL 容器中的类型。

3. 否则别担心。

这是一个公平的评估吗？如果某些东西不是异常(exception)，STL 中是否还有其他地方可以生成更优化的代码？如果是这样，这是哪个 STL 实现，需要将什么标记为 noexcept 才能工作，以及带来哪些性能优势(更少的内存分配，更低的复杂性)？

编辑:将 CashCow 的建议更改为措辞。

Answer 1

Is this a fair assessment?

不...在代码演化/维护过程中它不必要地脆弱。考虑一下如果您遵循此代码的规则会发生什么...

// awesome_lib.h
void f() noexcept; // out-of-line implementation: { }

// awesome_app.cpp
void c1() noexcept; // out-of-line implementation: { f(); }

// cool_app.cpp
void c2() noexcept; // out-of-line implementation: { f(); }

...然后说 f() 想通过异常报告一类新问题，因此它会删除 noexcept 并有条件地抛出...除非所有客户端代码调用 f() - c1, c2, ... 找到并更新，应用程序可能 std::terminate 而不是让异常传播到任何可能可用的 catch 子句。 你为什么想要那个？是的，你可以使用 noexcept 操作符来表达 c1 和 c2 的 noexcept 性质就 f 和其他被调用的函数而言，但这既冗长又脆弱。它不像 const 编译器错误可以帮助您保持一致。

在特定的分析线索优化机会需要时，最好有针对性地使用 noexcept。