如果类型为noexcept,C++ 11 STL中的哪些算法和容器可以更快？

Question

关于使用noexcept需要多少关注的问题,正在进行一场辩论.我们都知道noexcept对于编译器的优化器并没有真正做大量的事情,除了外部定义的代码,编译器否则必须假设它可以抛出,因为它无法知道它的实现,因此标记事物的唯一真正的其他性能优势noexcept用于使用std :: move_if_noexcept <>的代码,假定它主要是STL容器及其算法.

因此,该评估将是这样的:你不能使用noexcept,除非:

1. extern函数和类,其中编译器不知道可调用的实现.

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

3. 否则不要担心.

这是一个公平的评估吗？STL中还有其他地方可以产生更优化的代码吗？如果是这样,哪个STL实现是这个,什么需要标记为no,除了它工作,以及什么性能的好处导致(更少的内存分配,更低的复杂性)？

编辑:使CashCow建议更改措辞.

Answer 1

这是一个公平的评估吗？

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

// 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、 、 ... 的客户端代码，否则应用程序可能不会让异常发生传播到任何可用的子句。 你为什么想要那个？ 是的，您可以使用运算符来表达和的 noexcept 性质以及其他被调用函数，但这是冗长且脆弱的。这不像编译器错误可以帮助您保持一致。c2std::terminatecatchnoexceptc1c2fconst

最好有针对性地使用noexcept特定分析先导优化机会所需的地方。