C++ 嵌入式C++；：是否使用异常？

我意识到这可能是主观的，所以我会问一个具体的问题，但首先，背景：

我一直是一名嵌入式软件工程师，但通常在OSI堆栈的第3层或第2层。我不是一个真正的五金人。我通常做电信产品，通常是手持/手机，这通常意味着类似ARM7处理器的东西

现在我发现自己身处一个更为通用的嵌入式世界，在一家小型初创企业中，我可能会转向“功能不太强大”的处理器（存在主观因素）——我无法预测是哪个

我在阅读了大量关于嵌入式系统C++异常处理的争论，没有明确的答案。有一些关于可移植性的小问题，也有一些关于运行时的问题，但这似乎主要归结于代码大小（或者我读错了吗？）

现在，我必须决定是否使用或放弃异常处理——对整个公司来说，永远如此（它将进入一些非常核心的s/w）

这听起来可能像“一根绳子有多长”，但有人可能会回答“如果你的绳子是8051，那么不要。如果，哦，它是……”

---

我往哪边跳？超级安全&丢失一个好的功能，或者异常代码，以后可能会遇到问题？

就性能而言，我的理解是，异常实际上会减少代码正常执行路径的大小并提高性能，但会使异常/错误路径变得更昂贵。（通常要贵得多）

所以，如果你只关心性能，我会说以后不要担心。如果今天的CPU可以处理它，那么明天也可以

不过。在我看来，例外是那些要求程序员始终比合理预期的程序员更聪明的特性之一。所以我说-如果你能远离基于异常的代码。走开

---

看看陈雷蒙的。他说得比我好。

如果运行时环境支持异常，我会说适当地使用异常。处理异常情况的异常是可以接受的，并且根据实现的不同，可能会导致很少的开销。有些环境不支持它们，特别是在嵌入式环境中。如果你禁止他们，要小心解释原因。我曾经有一个家伙，当被告知不要使用异常时，他做了一个除以零的运算。不完全是我们所想的。

是否使用异常的选择实际上应该取决于它们是否适合您的程序的问题域

<>我在C++旧代码改装和一些更新代码中广泛使用C++异常。（提示：不要试图重新适应20年前在内存不足的环境中编写的C代码，因为它包含各种不一致的异常。这只是一场噩梦）

如果您的问题是在一个位置处理所有错误（例如，某种类型的TCP/IP服务器，其中每个错误条件都会遇到“断开连接并重试”），那么异常是好的-您可以在任何位置抛出异常，并且您知道在何处以及如何处理异常

---

另一方面，如果您的问题不适合集中错误处理，那么异常是一个巨大的难题，因为试图找出某个问题在哪里（或应该在哪里）得到处理很容易成为一项愚蠢的任务。仅仅通过查看代码就很难看出问题所在。相反，您必须查看给定函数的调用树，并查看该函数的异常将在何处结束，以确定是否存在问题。

异常的最大问题是它们没有可预测的执行时间。 因此，它们不适合硬实时应用程序（我猜大多数嵌入式应用程序不属于这一类）

第二个是（可能）增加二进制文件的大小

---

我建议您阅读一些您感兴趣的主题：在嵌入式（包括硬实时系统）中使用C++，以及如何通常执行异常处理以及它的开销。一般来说，你关注的是更便宜而不是更高的性能。我想这取决于嵌入式应用是什么。智能手机是一回事，但我想我还是喜欢我的电梯控制器，在可靠性和短语言特征覆盖上，已经在一些嵌入式系统上使用C++，我会说，不要使用C++，更别说例外。在运行时C++背后的所有东西都是调试的巨大痛苦。第一次应用程序程序员在静态对象的构造函数中调用OS原语时，你将处于一个受伤害的世界（<代码> Carl Norum，PPPrimeLimeIZE（））/>代码>在操作系统init之前，也许：“这不是一个反对C++的论点，这是一个反对在输入

main

之前运行代码的论点。您必须在输入

main

之前运行代码。堆栈还来自哪里？我不确定我是否明白你的意思。我认为Jon Kalb相当成功地解决了雷蒙德所谓的“坏”和“不坏”异常安全代码之间一目了然区别的问题。（虽然Raymond的“不错”代码在我看来仍然很糟糕，因为它使用的是裸体-

new

），但它们也意味着你不必像Raymond所说的那样“检查每一行代码”。John，我不同意例外会减少代码的大小。我看到数据（由IAR提供），与没有异常的代码相比，异常的使用使代码膨胀了数十%。技术报告中的一个亮点是：“因为标准库异常类的构造函数[…]需要std:：string类型的参数，此开销可能无意中包含在程序中”。许多异常使用std:：stri