编译器是否能够将 try/catch 优化为简单的 goto？

Question

在我看来，如果你有一些像这样的 C++ 代码：

int f()
{
  try {
    if( do_it() != success ) {
      throw do_it_failure();
    }
  } catch( const std::exception &e ) {
    show_error( e.what() );
  }
}

C++ 编译器应该能够将 throw 和 catch 优化为几乎简单的 goto。

然而，根据我查看反汇编和单步执行代码的经验，编译器总是跳过非常混乱的异常处理库。

他们为什么这么做？是否存在某些阻碍优化的语言要求？如果是的话怎么办：

int f()
{
  try { throw std::runtime_error("Boo!"); }
  catch ( const std::exception &e ) { std::cout << e.what() << std::endl; }
}

为什么编译器不只是将其重写为

int f()
{
  std::cout << "Boo!" << std::endl;
}

Answer 1

我认为所接受的答案即使没有错误，也是相当无用的，所以即使过了这么多年，我仍然觉得有必要提供一个正确的答案。

猜测为什么编译器实现者选择不在任何特定功能上投入精力只是，好吧......猜测。仅在特殊情况下抛出异常这一事实通常不会被认为是不优化此类代码性能的理由。相反，尽管抛出代码确实没有以牺牲非抛出代码为代价进行优化，但异常抛出和处理基础设施仍然经过非常仔细的优化。

此外，这段代码可能感觉很做作，不值得考虑，但事实并非如此：它可能是由于内联和优化更复杂的代码而产生的，优化它可能会产生更简单的代码，从而允许其他优化过程启动，或包含要进一步内联的函数。像这样的优化过程，当正确且高效地实现时，总是值得至少被考虑，无论原始代码看起来多么做作。否则，即使是像死代码消除这样的基本步骤也会被避免，因为“死代码不应该首先编写”。显然情况并非如此。

因此，我只是不同意已接受的答案。事实上，应该异常抛出异常并不是此代码未优化的原因。

原因纯粹是技术性的，clang 开发邮件列表中的这封电子邮件对此进行了解释： http://lists.llvm.org/pipermail/cfe-dev/2015-March/042035.html

总而言之，该语言允许在 catch 块内调用代码在“从未见过”异常对象的任何点重新抛出异常：

void g() { throw; }

因此，考虑OP代码：

int f()
{
  try { throw std::runtime_error("Boo!"); }
  catch ( const std::exception &e ) { std::cout << e.what() << std::endl; }
}

对于编译器所关心的，e.what() ，或者两次调用operator<<，可能会重新抛出异常，因此优化异常处理代码会破坏程序的语义。

确保情况并非如此，需要“整个程序知识”，如上面的电子邮件中所写。更简单的情况可以进行优化，例如：

int func() {
  try {
    throw 42;
  }catch(int x) {
    return x;
  }
}

上面的代码可以转化为return 42。没有任何技术原因阻碍它。

尽管如此，大多数常见的编译器都不会这样做（godbolt）。这次，我们可以从实际来源（上面链接的电子邮件）看出，Clang 开发人员（我们不能对其他编译器说什么）认为这种优化不值得，可能，因为它只适用捕获不执行函数调用的块。

不管怎样，该消息没有说明他们是否会接受补丁来实现这一点。

Answer 2

因为 do_it() 可能会在抛出 do_it_failure(); 之前抛出不同的异常

至于第二个示例，编译器可以执行此操作，但必须对其进行处理作为一个特例，何必去理会这种病态的情况呢？

Answer 3

他们为什么要这么做？

因为 C++ 异常适用于异常情况，并且异常情况下的性能并不重要。

C++ 的异常在设计时就考虑到了这一点，确保编译器供应商能够在不引发异常的常见情况下提供接近最佳的性能，但代价是在引发异常的奇怪情况下性能低于可能的性能。

从一开始就鼓励用户仅在特殊情况下使用异常，并鼓励实现者优化无异常情况（析构函数地址必须存储在某处，以便在异常发生时调用析构函数），但以异常情况为代价。案例。
虽然实施者当然可以花费资源来优化奇怪的例外情况，但大多数用户不会喜欢这样，因为总是有很多更重要的事情需要改进。