我在一个嵌入式平台上工作,我不习惯将 60k 添加到我的二进制文件中。无论如何,有一些论点可以避免嵌入式系统上的异常,但我认为它们中的大多数都是虚假的。例外是有道理的,但我无法证明目前的成本是合理的。我正在使用 gcc 4.6.3,也许我错过了一个选项,或者这可能只是异常的开销。我试过-Os,并将例外更改为longjmp,但无济于事。我可能错过了什么。
感谢您的任何见解。
我在一个嵌入式平台上工作,我不习惯将 60k 添加到我的二进制文件中。无论如何,有一些论点可以避免嵌入式系统上的异常,但我认为它们中的大多数都是虚假的。例外是有道理的,但我无法证明目前的成本是合理的。我正在使用 gcc 4.6.3,也许我错过了一个选项,或者这可能只是异常的开销。我试过-Os,并将例外更改为longjmp,但无济于事。我可能错过了什么。
感谢您的任何见解。
You can turn off exceptions in GCC using -fno-exceptions
.
However, you can't have your cake and eat it too. Turning off exceptions means you can't catch them, and it will also break if you link against code compiled with exceptions on. But it does reduce the binary size as you intended.
Code without exceptions (but with the same level of error checking) is ugly as sin but it's a price you have to pay.
Lovely exception-free robust code example in C :)
error_t foo(void) {
if (!do_foo()) {
error_code = E_FOO;
goto bail;
}
if (!do_bar()) {
error_code = E_BAR;
goto bail;
}
/* repeat 100 times */
bail:
cleanup();
return error_code;
}
第一,不!
异常处理会带来一些成本,主要是要求 RTTI 支持主要是恕我直言(到目前为止还没有通过实验证明这一点)。RTTI 支持将导致代码文本段的一些费用使用,特别是如果有很多模板实例化(例如,广泛使用具有多种类型的 STL 模板类/容器类)。
另一方面,与减少 newlib 所需实现的其他可能性相比,60k 开销的成本并没有那么多。
你真的应该三思而后行让异常支持消失!
有趣的是,我今天和我的同事讨论了这个话题,当时我们面临一个明显由内存不足情况引起的错误。有问题的固件(以及它与 FreeRTOS 的操作系统绑定)不支持异常,但如果您无法使用new()
. 这可能会使用一些 STL 诱导算法发生,并且您没有机会使用try/catch
故障块(例如使用简单的std::vector
)来拦截它。
因此,您应该决定如何处理错误情况,不使用或不使用异常,并确保提供一致的行为,例如使用常见的 STL 模式等,并权衡您为.text
节大小支付的成本。