面向对象对嵌入式系统不利吗？为什么？

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

想要改进这个问题？更新问题，以便可以通过编辑这篇文章用事实和引文来回答它。

5 年前已关闭。

Answer 1

虽然我不确定它是否回答了你的问题，但我可以总结一下我以前的公司源代码是纯 C 的原因。

首先值得总结一下情况：

• 我们想要编写大量的“核心”代码，这些代码可以在不同平台之间高度移植。大量 ARM 嵌入式系统（主要是中档手机；智能手机和运行不同时期 RTOS 的手机）
• 平台通常都有一个可用的 C 编译器，尽管有些不支持浮点“double”。
• 在某些情况下，平台对标准库有合理的实现，但在许多情况下却没有。
• 大多数平台上都没有 C++ 编译器，并且在提供 C++ 标准库、STL 或异常的支持的地方，情况也存在很大差异。
• 调试器通常不可用（可以将调试 printfs 发送到的串行端口被认为是一种奢侈）
• 我们总是可以访问合理数量的内存，但通常无法访问合理的 malloc() 实现

鉴于此，我们完全使用 C 语言工作，即使如此，也只有一组有限的 C 89。生成的代码具有高度可移植性。不过，我们经常使用面向对象的概念。

如今，“嵌入式”是一个非常广泛的定义。它涵盖了从没有 RAM 或 C 编译器的 8 位微处理器到本质上高端 PC（尽管不运行 Microsoft Windows）的所有内容 - 我不知道您的项目/公司在这个范围内的位置。

Answer 2

从表面上看，动态内存分配是与面向对象软件设计完全不同的概念，所以它完全是错误的。您可以采用面向对象的设计，而不使用动态内存分配。

事实上，你可以在一定程度上用 C 语言进行面向对象（这就是 Linux 内核所做的）。许多嵌入式开发人员不喜欢 C++ 的真正原因是它非常复杂，并且很难用它编写直接且可预测的代码。 Linus 最近有一篇不错的咆哮< /a> 为什么他不喜欢 C++（它比他的旧的更好、更合理，我承诺）。可能大多数人都没有很好地表达它。

Answer 3

是什么让你说 C++ 是面向对象的？ C++ 是多范式的，由于其开销，并非 C++ 提供的所有功能都对嵌入式市场有用。 （所以......只是不要使用这些功能！问题解决了！）

Answer 4

面向对象非常适合嵌入式系统。它非常关注封装、数据隐藏和代码共享。人们可以拥有无​​需划分或动态内存分配的面向对象嵌入式系统。

无论是面向对象、面向数据还是过程编程，划分和动态内存分配都是嵌入式系统的敌人。这些概念可能会也可能不会用于面向对象设计的实现。

面向对象允许 UART 类在不知道消息对象内容的情况下传输消息对象的实例。消息可以是基类并具有多个后代类。

C++ 语言通过允许构造函数、复制构造函数和析构函数来帮助促进嵌入式系统中的安全编码，这些函数只有在最严格的 C 语言嵌入式系统中才会被记住。

使用 C 语言进行异常处理也是一件痛苦的事情。 C++ 提供了更好的嵌入到该语言中的设施。

C++ 语言提供了用于编写通用代码来处理不同数据类型的模板。一个典型的例子是环形缓冲区或循环队列。在 C 语言中，必须使用“指向 void 的指针”，以便可以传递任何对象。 C++ 提供了一个模板，这样人们就可以编写一个 Circular_Queue 类，它可以处理不同的数据类型，并具有更好的编译时类型检查。

继承可以实现更好的代码共享。共享代码被分解到基类中，并且可以创建共享相同功能的子类；通过继承。

C语言提供函数指针。 C++ 语言为函数对象（带有属性的函数指针）提供了便利。

抱歉，我只是不喜欢那些因为谣言以及对 C++ 的了解和经验很少而将嵌入式系统限制为 C 语言的人。

Answer 5

面向对象设计本身并不坏。答案就在你的引述中。特别是在实时嵌入式系统中，您希望使代码尽可能轻量和高效。您引用中提到的内容（对象、除法、动态内存分配）相对重量级，通常可以用更简单的替代方案替换（例如，使用位操作来近似除法、在堆栈上分配内存或使用静态池）以改进时间关键型系统中的性能。

Answer 6

“面向对象”对于嵌入式系统来说并不是什么坏事。 OO 只是一种思考软件的方式。

对于嵌入式系统来说，不好的地方是，一般来说，它们的调试器不太复杂，可以这么说，C++“在你背后”做了很多疯狂的事情。那些难以访问的代码会让你发疯。

Answer 7

C++ 的设计理念是不要为不使用的东西付费。因此，除了缺乏良好的嵌入式编译器之外，没有真正的原因。

也许 CFront 可以将 C++ 编译为 C，它有无数的编译器...

编辑：Comeau 编译器将 C++ 转换为纯 C，因此无编译器参数不会撑不住了

Answer 8

正如其他人所指出的，“嵌入式”包含广泛且多样的硬件/软件选项。但是...

您给出的报价将使微控制器嵌入式类型颤抖。动态分配是一个禁忌，如果出现错误，系统就会以不可预测的方式崩溃。强烈建议不要使用除法，因为它们会占用执行时间永远。对象之所以不被鼓励，是因为它们往往携带大量“东西”，所有这些“东西”都会占用空间，而微控制器没有任何空间。

我认为嵌入式是小型且具体的项目，您不必太担心可扩展性或可移植性。您可以用 C 语言编写干净的代码，该代码仅可靠地执行您希望设备执行的操作。您选择一个芯片系列，这样您就可以在不同的硬件选项之间移动（几乎）相同的代码，并对您编写的端口进行细微调整或配置熔丝的初始化。

因此，您不需要定义

1. 4 轮运输车
2. 丰田
3. ，

因为您只在丰田汽车上工作。凯美瑞和卡罗拉之间的加速度差异作为常数存储在寄存器中。

Answer 9

如上所述，面向对象/malloc/数学在你背后所做的事情会带来惩罚——无论是代码大小还是CPU周期，这在嵌入式中通常是短缺的。

举个例子，在循环中包含 sqrt() 函数会在递归计算中增加太多开销，因此我们必须将其删除并对其进行快速近似，如果我没记错的话，请使用查找表。

无论如何，使用您喜欢的任何工具/语言，但您至少需要能够揭开盖子并检查在您背后生成了多少额外代码。

Answer 10

编程始终是使用正确的工具来完成工作。没有固定的答案，在嵌入式世界中尤其如此。如果您想熟练掌握嵌入式开发，您将像熟悉 C++ 一样熟悉 C。

Answer 11

首先，我们来区分一下：

因此，我们希望人们不要使用divide ...、malloc ...或其他会带来巨大损失的面向对象实践。

除法和 malloc 并不是面向对象编程所独有的，它们也存在于过程语言中（并且大概是函数式的，以及您可能想到的任何其他范例）。

如果系统的资源足够有限，那么除法和 malloc 在嵌入式系统上可能会成为问题，这是事实，但无论您使用哪种编程范例，它们都将成为问题。

---

主要问题是“面向对象对嵌入式系统有害吗？”。

首先，“面向对象”的范围相当广泛。有些人对于它的实际含义有不同的看法。有一个极简主义的定义，其中对象本质上只是一组函数（或“方法”）和数据，还有一个更“纯粹”的定义，还包括继承和多态性等功能。

如果您采用 OOP 的极简定义，那么不会 - OOP 对于嵌入式系统来说并不坏。它确实取决于语言，但使用对象完全有可能与不使用对象一样便宜（在某些情况下可能更便宜）。在 C++ 中，一个对象（没有虚拟方法，我稍后会介绍）占用的内存不会比它的各个字段（如果它们不是对象的一部分）占用的内存多。在 C++ 中，对象（的大小）等于其各部分（的大小）之和。

然而，如果您采用 OOP 的“清教徒”观点并坚持包含继承和多态性，那么答案是“是的，这很糟糕”。继承也许不太重要（取决于语言），但通过虚拟方法实现的多态性确实是一个内存消耗者。虚拟函数通常通过维护一个“vtable”（虚拟方法表）来实现，该表存储指向正确函数的指针，并且每个对象必须存储一个指向其 vtable 的指针以启用动态分派（调用虚函数）才能正常工作。在某些情况下，继承可以比不需要继承的解决方案使用更多的内存 - 通常在将继承与组合进行比较时，组合有时会使用更少的内存。

最后一点，特别是对于 C++ 的情况（因为这通常是人们谈论在嵌入式系统上使用 OOP 时的意思）。人们经常说“C++ 在你背后做了奇怪的事情”——它确实做了一些事情，但在查看代码时这些事情并不是立即显而易见的，例如生成我之前提到的 vtable，但是它不会“在背后做这些事情”。你的背部”试图阻止你，它做这些事情是因为它们只是需要实现正在使用的功能。总的来说，“幕后”发生的有害事情很少，而且它所做的事情并不完全神秘或神秘，它们通常是众所周知的，并且是程序员在编程时应该注意的事情。嵌入式系统。如果您不了解它们，那么您就没有正确了解您的工具，您应该对它们进行更多研究。

话虽如此，请记住，人们可以自由选择使用和不使用哪些语言功能。避免使用虚拟函数等更昂贵的功能是绝对有意义的，但仅仅因为它有一些昂贵的完全可选功能（例如虚拟函数）而放弃整个语言（例如 C++）是没有意义的。函数）——这简直就是把婴儿和洗澡水一起倒掉了。