有时间要求的软件不能用异常

quora上有个人认为，基于表的异常，不是完全的零成本：
/Do-exceptions-slow-down-C++-programs-even-if-no-exception-is-thrown-since-it-has-to-be-checked-whether-a-function-has-returned-or-not/answer/David-Vandevoorde

在 20 世纪 90 年代中后期，惠普为其 aC++ 编译器引入了新的 ABI。对于他们的异常处理策略，他们提出了上述表驱动方法的变体（我是该编译器的前端负责人，但几乎没有直接参与这项工作）。它没有让throw-expression 运行时库执行所需的析构函数，而是将控制权暂时移交回函数中引发异常的部分（称为着陆垫）。编译器可以完全控制该代码，并且可以简单地将每个函数建模为具有两个返回路径：一个是在调用后立即返回到代码的常用路径，另一个是连接到登陆台的异常路径。（另请参阅我对 C++ 编译器如何实现 RAII？ 的回答）使用该模型，编译器能够再次执行在异常进入环境之前可以执行的所有优化。（这个模型后来被 Itanium ABI 采用，这是现代 GCC 和 Clang 编译器在类 Unix 平台上使用的。我相信微软在其编译器的某些版本中做了类似的事情。）

然而，即使该模型也不是真正的“零成本”，尽管它非常接近。对两条返回路径进行建模比对一条返回路径进行建模需要更多工作，尽管其中一条路径（特殊路径）通常不需要像另一条路径那样优化。因此，优化器的资源预算会承受更大的压力，有时它会放弃在没有异常控制流的情况下可能执行的某些优化。

我还应该注意到，使用这些方案，特殊路径可能会非常慢。所涉及的代码通常位于任何缓存之外，并且通常涉及大量间接分支（这对现代 CPU 的分支预测硬件来说是一个挑战）。因此，如果异常情况在您的代码中并不那么异常，那么使用 C++ 异常的替代方案可能会更好。事实上，C++ 标准化委员会正在考虑标准化此类替代方案。同时，std::optional对于可能无法产生结果的函数的返回值建模通常很有用。

【 在 nogoarea 的大作中提到: 】
: 不能保证实时性吧
--
FROM 222.128.162.*