不主动抛异常
捕获一些SB抛出来的异常
使用 [[nodiscard]]
【 在 z16166 的大作中提到: 】
: 说出你的故事
:
--
FROM 106.11.31.*

你的意思是boost、qt这些库的作者都是SB吗，这两个东西是使用异常的

抛了异常，但是事先没提供对应的文档说明，才值得骂吧

【 在 overcomeunic 的大作中提到: 】
: 不主动抛异常
: 捕获一些SB抛出来的异常
: 使用 [[nodiscard]]
--
FROM 222.128.162.*

我特定测试了一下，性能简直不是一个量级的。
一次异常，抵得上百万次数学运算。这还是在还没有真正抛出的情况。



【 在 z16166 的大作中提到: 】
: 你都没提供证据证明"C++异常肯定会影响性能"，就武断下结论，属于“顽固派”的一种。
: 这就跟楼主顶楼里写的“C++异常会把调用栈搞没”一样属于无脑推测但又不验证分析的，不值得一驳。
: 为啥呢，因为张嘴就来很简单，但是要分析得下工夫、考验技术，所以无脑懒人都是规避后者的，毕竟上下嘴唇一张一合就能唾沫四溅地开喷，多爽啊
: ...................
--来自微微水木3.5.14
--
FROM 183.193.16.*

你测试的啥编译器？

msvc x64、gcc都是zero-cost的，不抛异常时没开销，发生异常时才有开销。

【 在 foliver 的大作中提到: 】
: 我特定测试了一下，性能简直不是一个量级的。
: 一次异常，抵得上百万次数学运算。这还是在还没有真正抛出的情况。
:
--
FROM 222.128.162.*

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

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.*