12

我们今天在工作中一直在讨论这个话题，我们谁也无法对这个问题给出明确的答案。考虑以下情况：

int foo()
{
  int err;

  err = some_call(1);

  if (err != 0)
    return err;

  err = some_call(2);

  if (err != 0)
    return err;

  err = some_call(3);

  if (err != 0)
    return err;

  err = some_call(4);

  if (err != 0)
    return err;

  bar();

  return err;
}

有很多代码重复。显然，这可以用宏分解，遗憾的是不能用模板分解（因为 return 子句）。或者至少不是直接的。

现在的问题是，如果我们用异常替换那些返回错误代码，并立即捕获这些异常，编译器是否允许并且足够聪明以检测模式并完全避免抛出异常？

这是我的意思的说明：

int foo()
{
  try
  {
    // some_call now throws a ErrorReturned exception that contains the error code upon failure.
    some_call(1);
    some_call(2);
    some_call(3);
    some_call(4);
  }
  catch (ErrorReturned& ex)
  {
    return ex.error_code();
  }

  bar();

  return 0;
}

现在，没有当前的性能问题，所以是的，我们不需要优化甚至关心它。这更多地是为了了解允许编译器做什么。

简而言之，这是一种“好”的做法吗？如果是这样，编译器可以通过不抛出异常来优化它吗？（假设异常构造没有副作用）

4

1 回答 1

12

“编译器足够聪明”似乎暗示异常在您的项目中没有任何用途，如果是这种情况，您首先不应该使用它们（当然，除非您实际上有可能获得异常）。

简短回答：不，编译器不会根据您使用它们的模式删除您的异常/异常处理。

当你使用 try/catch 时，它处理的异常被添加到主异常表中；该表可以被监视、连接、添加和删除。仅仅因为您立即捕获异常并不意味着其他事情也不会发生。

Side Source：
一篇论文Optimizing Away C++ Exception Handling概述了所有（几乎所有）当前与异常有关的优化实现。在整个过程中，它表明目前它们没有在编译时被剥离，而是对它们进行了优化。该论文本身建议增强 EH（异常处理）以消除不必要的异常，总体而言，这是一本很好的读物。

更新（其他来源）
进一步研究该主题，GCC 编译器似乎没有优化掉异常；但是，它确实提供了这样做的选项：-fno-exceptions. abort()此选项将删除所有异常并直接用调用 替换它们。

另一个来源（在 StackOverflow 上）没有直接提到“删除异常”，但确实概述了对异常setjmp/longjmp和零成本的两种优化。可以通过突出显示实际增强而不提及“完全消除异常”来推断没有这样的优化（但是，至少对于提到的编译器）。可以在此处找到包含有关这些优化的更详细信息的另一个来源。

于 2013-10-15T12:28:41.810 回答