13

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

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

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

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

  3. 否则不要担心。

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

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

4

1 回答 1

2

这是一个公平的评价吗？

不......在代码演变/维护期间它是不必要的脆弱。考虑一下如果您遵循此代码的规则会发生什么...

// 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特定分析线索优化机会所需的位置。

于 2014-10-21T11:24:02.320 回答