C++ 异常处理增加了多少占用空间

How much footprint does C++ exception handling add(C++ 异常处理增加了多少占用空间)

问题描述

这个问题对于嵌入式开发尤其重要.异常处理为生成的二进制输出增加了一些足迹.另一方面，无一例外，错误需要以其他方式处理，这需要额外的代码，最终也会增加二进制大小.

This issue is important especially for embedded development. Exception handling adds some footprint to generated binary output. On the other hand, without exceptions the errors need to be handled some other way, which requires additional code, which eventually also increases binary size.

我对你的经历很感兴趣，尤其是:

I'm interested in your experiences, especially:

1. 您的编译器为异常处理添加的平均占用空间是多少(如果您有此类测量)?
2. 就二进制输出大小而言，异常处理是否真的比其他错误处理策略更昂贵(很多人这么说)?
3. 对于嵌入式开发，您建议采用什么错误处理策略?

请仅将我的问题作为指导.欢迎任何意见.

Please take my questions only as guidance. Any input is welcome.

附录:有没有人有具体的方法/脚本/工具，对于特定的 C++ 对象/可执行文件，将显示由编译器生成的代码和专用于异常处理的数据结构占用的加载内存占用的百分比?

Addendum: Does any one have a concrete method/script/tool that, for a specific C++ object/executable, will show the percentage of the loaded memory footprint that is occupied by compiler-generated code and data structures dedicated to exception handling?

推荐答案

当异常发生时，会产生时间开销，这取决于您如何实现异常处理.但是，顺便说一句，应该导致异常的事件的严重性将花费同样多的时间来使用任何其他方法来处理.为什么不使用高度支持的基于语言的方法来处理此类问题?

When an exception occurs there will be time overhead which depends on how you implement your exception handling. But, being anecdotal, the severity of an event that should cause an exception will take just as much time to handle using any other method. Why not use the highly supported language based method of dealing with such problems?

GNU C++ 编译器默认使用零成本模型，即在不发生异常时没有时间开销.

The GNU C++ compiler uses the zero–cost model by default i.e. there is no time overhead when exceptions don't occur.

由于有关异常处理代码和本地对象偏移量的信息可以在编译时计算一次，因此此类信息可以保存在与每个函数关联的单个位置，但不能保存在每个 ARI 中.您基本上从每个 ARI 中删除了异常开销，从而避免了将它们压入堆栈的额外时间.这种方法称为异常处理的零成本模型，前面提到的优化存储称为影子堆栈.- Bruce Eckel，在 C++ 中思考第 2 卷

Since information about exception-handling code and the offsets of local objects can be computed once at compile time, such information can be kept in a single place associated with each function, but not in each ARI. You essentially remove exception overhead from each ARI and thus avoid the extra time to push them onto the stack. This approach is called the zero-cost model of exception handling, and the optimized storage mentioned earlier is known as the shadow stack. - Bruce Eckel, Thinking in C++ Volume 2

大小复杂度开销不容易量化，但 Eckel 表示平均为 5% 和 15%.这将取决于您的异常处理代码的大小与应用程序代码的大小之比.如果您的程序很小，那么异常将占二进制文件的很大一部分.如果您使用的是零成本模型，那么异常将占用更多空间来消除时间开销，因此，如果您关心空间而不是时间，则不要使用零成本编译.

The size complexity overhead isn't easily quantifiable but Eckel states an average of 5 and 15 percent. This will depend on the size of your exception handling code in ratio to the size of your application code. If your program is small then exceptions will be a large part of the binary. If you are using a zero–cost model than exceptions will take more space to remove the time overhead, so if you care about space and not time than don't use zero-cost compilation.

我的观点是大多数嵌入式系统都有足够的内存，如果您的系统有 C++ 编译器，您就有足够的空间来包含异常.我的项目使用的 PC/104 计算机有几 GB 的辅助内存，512 MB 的主内存，因此没有异常空间问题——不过，我们的微控制器是用 C 编程的.我的启发是如果有一个主流的 C++ 编译器它，使用异常，否则使用 C".

My opinion is that most embedded systems have plenty of memory to the extent that if your system has a C++ compiler you have enough space to include exceptions. The PC/104 computer that my project uses has several GB of secondary memory, 512 MB of main memory, hence no space problem for exceptions - though, our micorcontrollers are programmed in C. My heuristic is "if there is a mainstream C++ compiler for it, use exceptions, otherwise use C".

这篇关于C++ 异常处理增加了多少占用空间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！