我的硬件 C++ 和 C89 上有两个编译器
我正在考虑将 C++ 与类一起使用但没有多态性（以避免 vtables）。我想使用 C++ 的主要原因是：
在为非常有限的硬件（4kb 的 RAM）进行开发时，您是否认为有任何理由坚持使用 C89？
谢谢你的回答，他们真的很有帮助！
我想通了这个主题，我会坚持使用 C，主要是因为：
很难接受一个答案，因为您提供了这么多好的答案。不幸的是，我无法创建一个 wiki 并接受它，所以我会选择一个让我思考最多的答案。
对于资源非常受限的目标（例如 4KB 的 RAM），我会先用一些样本进行测试，然后再投入大量无法轻易移植回纯 ANSI C 实现的工作。
Embedded C++ 工作组确实提出了该语言的标准子集和标准库的标准子集以与之配套。不幸的是，当 C User's Journal 死了时，我忘记了这项工作。看起来Wikipedia上有一篇文章，并且该委员会仍然存在。
在嵌入式环境中，您确实必须小心内存分配。为了强制执行这种关心，您可能需要将全局operator new()及其朋友定义为甚至无法链接的东西，以便您知道它没有被使用。new另一方面，当与稳定、线程安全和延迟保证的分配方案一起明智地使用时，布局可能是您的朋友。
内联函数不会引起太大问题，除非它们足够大以至于它们本来应该是真正的函数。当然，他们替换的宏也有同样的问题。
模板也可能不会导致问题，除非它们的实例化运行异常。对于您确实使用的任何模板，请审核您生成的代码（链接映射可能有足够的线索）以确保仅发生您打算使用的实例化。
可能出现的另一个问题是与调试器的兼容性。其他可用的硬件调试器对与原始源代码交互的支持非常有限，这并不罕见。如果您实际上必须在汇编中进行调试，那么有趣的 C++ 名称修饰可能会给任务增加额外的混乱。
RTTI、动态转换、多重继承、重度多态性和异常都伴随着一些运行时成本。如果使用这些功能，其中一些功能会花费整个程序的成本，其他功能只会增加需要它们的类的权重。了解差异，明智地选择高级功能，至少了解粗略的成本/收益分析。
在小型嵌入式环境中，您将直接链接到实时内核或直接在硬件上运行。无论哪种方式，您都需要确保您的运行时启动代码正确处理 C++ 特定的启动杂务。这可能就像确保使用正确的链接器选项一样简单，但是由于通常可以直接控制通电复位入口点的源，因此您可能需要对其进行审核以确保它可以完成所有操作。例如，在我工作的一个 ColdFire 平台上，开发工具附带了一个 CRT0.S 模块，该模块具有 C++ 初始化程序，但注释掉了。如果我直接从盒子里使用它，我会被其构造函数根本没有运行过的全局对象所迷惑。
此外，在嵌入式环境中，通常需要在使用硬件设备之前对其进行初始化，如果没有操作系统也没有引导加载程序，那么就是您的代码执行此操作。您需要记住，全局对象的构造函数在调用之前 main()运行，因此您需要修改本地 CRT0.S（或其等效项）以在调用全局构造函数本身之前完成硬件初始化。显然，顶峰main()为时已晚。
使用 C 而不是 C++ 的两个原因：
此外，原始问题和一些评论都提到了 4 Kb of RAM。对于典型的嵌入式处理器，RAM 的数量（大部分）与代码大小无关，因为代码是从闪存存储和运行的。
当然，代码存储空间的数量是需要牢记的，但随着市场上出现新的、容量更大的处理器，除了对成本最敏感的项目之外，它不再像过去那样成为问题。
关于将 C++ 的子集用于嵌入式系统：现在有一个MISRA C++标准，可能值得一看。
编辑：另见这个问题，它引发了关于嵌入式系统的 C 与 C++ 的辩论。
不会。在进行嵌入式开发时，可以避免任何可能导致问题的 C++ 语言特性（运行时多态性、RTTI 等）。有一个嵌入式 C++ 开发人员社区（我记得在旧的 C/C++ 用户日志中阅读了嵌入式开发人员使用 C++ 的专栏），如果选择那么糟糕，我无法想象他们会非常直言不讳。
C++ 性能技术报告是这类事情的一个很好的指南。请注意，它有一个关于嵌入式编程问题的部分！
此外，++ 在答案中提到了嵌入式 C++。该标准不是 100% 符合我的口味，但在决定可能放弃 C++ 的哪些部分时，它是一个很好的参考。
在为小型平台编程时，我们禁用异常和 RTTI，避免虚拟继承，并密切关注我们周围存在的虚拟函数的数量。
不过，您的朋友是链接器映射：经常检查它，您会很快发现代码源和静态内存膨胀。
之后，标准的动态内存使用注意事项适用：在您提到的受限环境中，您可能根本不想使用动态分配。有时您可以摆脱用于小型动态分配的内存池，或“基于帧”的分配，您可以在其中预先分配一个块并在以后丢弃整个事情。
我建议使用 C++ 编译器，但限制您使用 C++ 特定功能。您可以在 C++ 中像 C 一样进行编程（在执行 C++ 时包含 C 运行时，尽管在大多数嵌入式应用程序中您无论如何都不会使用标准库）。
您可以继续使用 C++ 类等，只需
作为一名固件/嵌入式系统工程师，我可以告诉你们为什么 C 仍然是 C++ 的第一选择的一些原因，是的，我对它们都很流利。
1) 我们开发的一些目标有 64kB 的 RAM 用于代码和数据，所以你必须确保每个字节计数，是的，我已经处理了代码优化以节省 4 个字节，这花了我 2 小时，这就是2008 年。
2) 每个 C 库函数在我们将它们放入最终代码之前都经过审查，因为大小限制，所以我们不希望人们使用除法器（没有硬件除法器，所以需要一个大库），malloc（因为我们没有堆，所有内存都是从 512 字节块中的数据缓冲区分配的，并且必须进行代码审查），或者其他会带来巨大损失的面向对象的做法。请记住，您使用的每个库函数都会计数。
3) 听说过覆盖这个词吗？你的代码空间太小了，有时你不得不用另一组代码交换东西。如果调用库函数，则库函数必须是常驻的。如果只在覆盖函数中使用它，那么依赖于太多面向对象的方法会浪费大量空间。所以，不要假设任何 C 库函数，更不用说 C++ 被接受了。
4) 由于有限的硬件设计（即以某种方式连接的 ECC 引擎）或应对硬件错误，需要进行强制转换甚至打包（未对齐的数据结构跨越字边界）。您不能隐含地假设太多，那么为什么要过多地面向对象呢？
5) 最坏情况：消除一些面向对象的方法将迫使开发人员在使用可能爆炸的资源之前进行思考（即在堆栈上而不是从数据缓冲区中分配 512 字节），并防止一些潜在的最坏情况没有一起测试或消除整个代码路径。
6）我们确实使用了很多抽象来使硬件与软件隔离，并使代码尽可能可移植，并且模拟友好。硬件访问必须包装在宏或内联函数中，这些函数在不同平台之间有条件地编译，数据类型必须转换为字节大小而不是特定于目标，不允许直接使用指针（因为某些平台假设内存映射 I/O 是与数据存储器相同）等。
我可以想到更多，但你明白了。我们固件人员确实接受过面向对象的培训，但嵌入式系统的任务可能是如此面向硬件和低级，以至于它本质上不是高级或抽象的。
顺便说一句，我从事的每一项固件工作都使用源代码控制，我不知道你从哪里得到这个想法。
- 来自 SanDisk 的一些固件专家。
我听说有些人更喜欢 C 用于嵌入式工作，因为它更简单，因此更容易预测将生成的实际代码。
我个人认为编写 C 风格的 C++（使用模板进行类型安全）会给你带来很多好处，但我看不出有什么真正的理由不这样做。
我个人的偏好是 C，因为：
- 我知道每一行代码在做什么（和成本）
- 我不太了解 C++，无法知道每一行代码在做什么（以及成本）
为什么人们会这样说？除非您检查 asm 输出，否则您不知道 C 的每一行都在做什么。C++ 也是如此。
例如，这个无害的语句会产生什么 asm：
a[i] = b[j] * c[k];
它看起来很无辜，但是基于 gcc 的编译器为 8 位微控制器生成了这个 asm
CLRF 0x1f, ACCESS
RLCF 0xfdb, W, ACCESS
ANDLW 0xfe
RLCF 0x1f, F, ACCESS
MOVWF 0x1e, ACCESS
MOVLW 0xf9
MOVF 0xfdb, W, ACCESS
ADDWF 0x1e, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfa
MOVF 0xfdb, W, ACCESS
ADDWFC 0x1f, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0xfee, 0x1c
NOP
MOVFF 0xfef, 0x1d
NOP
MOVLW 0x1
CLRF 0x1b, ACCESS
RLCF 0xfdb, W, ACCESS
ANDLW 0xfe
RLCF 0x1b, F, ACCESS
MOVWF 0x1a, ACCESS
MOVLW 0xfb
MOVF 0xfdb, W, ACCESS
ADDWF 0x1a, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfc
MOVF 0xfdb, W, ACCESS
ADDWFC 0x1b, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0xfee, 0x18
NOP
MOVFF 0xfef, 0x19
NOP
MOVFF 0x18, 0x8
NOP
MOVFF 0x19, 0x9
NOP
MOVFF 0x1c, 0xd
NOP
MOVFF 0x1d, 0xe
NOP
CALL 0x2142, 0
NOP
MOVFF 0x6, 0x16
NOP
MOVFF 0x7, 0x17
NOP
CLRF 0x15, ACCESS
RLCF 0xfdf, W, ACCESS
ANDLW 0xfe
RLCF 0x15, F, ACCESS
MOVWF 0x14, ACCESS
MOVLW 0xfd
MOVF 0xfdb, W, ACCESS
ADDWF 0x14, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfe
MOVF 0xfdb, W, ACCESS
ADDWFC 0x15, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0x16, 0xfee
NOP
MOVFF 0x17, 0xfed
NOP
产生的指令数量很大程度上取决于：
在微型嵌入式世界中尤其如此，处理器没有设置为处理 C。所以我的答案是 C 和 C++ 彼此一样糟糕，除非你总是检查 asm 输出，在这种情况下它们彼此一样好。
雨果
我认为没有理由使用 C 而不是 C++。无论您在 C 中可以做什么，您也可以在 C++ 中完成。如果您想避免 VMT 的开销，请不要使用虚拟方法和多态性。
但是，C++ 可以提供一些非常有用的惯用语，而无需任何开销。我的最爱之一是 RAII。就内存或性能而言，类不一定很昂贵......
我在 IAR Workbench 上为 ARM7 嵌入式平台编写了一些代码。我强烈建议依靠模板进行编译时优化和路径预测。避免像瘟疫一样的动态投射。正如 Andrei Alexandrescu 的《现代 C++ 设计》一书中所述，使用特征/策略对您有利。
我知道，这可能很难学习，但我也确信您的产品将从这种方法中受益。
一个很好的理由，有时是唯一的理由是仍然没有针对特定嵌入式系统的 C++ 编译器。例如，Microchip PIC微控制器就是这种情况。它们很容易编写，并且有一个免费的 C 编译器（实际上是 C 的一个轻微变体），但看不到 C++ 编译器。
对于受限于 4K 内存的系统，我会使用 C，而不是 C++，这样您就可以确保看到正在发生的一切。C++ 的问题在于，它使用更多的资源（CPU 和内存）比看代码要容易得多。（哦，我将创建另一个 BlerfObject 来执行此操作……哎呀！内存不足！）
如前所述，您可以在 C++ 中执行此操作（没有 RTTI、没有 vtables 等），但是您将花费尽可能多的时间来确保您的 C++ 使用不会像在 C 中执行等效操作那样远离您.
人类的大脑通过尽可能多地评估来处理复杂性，然后决定关注什么是重要的，然后丢弃或贬低其余的。这是营销中品牌化背后的全部基础，主要是图标。
为了对抗这种趋势，我更喜欢 C 而不是 C++，因为它迫使你思考你的代码，以及它如何更紧密地与硬件交互 - 无情地接近。
从长期的经验来看，我相信 C 会迫使你想出更好的问题解决方案，部分原因是不妨碍你，而不是强迫你浪费大量时间来满足一些编译器编写者认为是个好主意的约束，或弄清楚“幕后”发生了什么。
在这种情况下，像 C 这样的低级语言让你花大量时间专注于硬件和构建良好的数据结构/算法包，而高级语言让你花很多时间摸不着头脑想知道那里发生了什么，以及为什么你不能在你的特定上下文和环境中做一些完全合理的事情。打败你的编译器（强类型是最严重的违规者）并不是对时间的有效利用。
我可能很适合程序员的模具——我喜欢控制。在我看来，这不是程序员的人格缺陷。控制是我们得到报酬的事情。更具体地说，完美的控制。C 比 C++ 给你更多的控制权。
就我个人而言，拥有 4kb 的内存，我会说你并没有从 C++ 中获得更多的里程，所以只需选择一个看起来最适合这项工作的编译器/运行时组合，因为语言可能并不重要。
请注意，这也不仅仅是关于语言，因为图书馆也很重要。通常 C 库的最小大小略小，但我可以想象针对嵌入式开发的 C++ 库被缩减了，所以一定要进行测试。
在为非常有限的硬件（4kb 的 RAM）进行开发时，您是否认为有任何理由坚持使用 C89？
就个人而言，当谈到嵌入式应用程序时（当我说嵌入式时，我并不是指 winCE、iPhone 等。今天臃肿的嵌入式设备）。我的意思是资源有限的设备。我更喜欢 C，尽管我也使用过很多 C++。
例如，您正在谈论的设备具有4kb的 RAM，因此我不会考虑使用 C++。当然，您可以使用 C++ 设计一些小的东西，并像其他帖子所建议的那样限制您在应用程序中的使用，但 C++“可能”最终可能使您的应用程序在幕后变得复杂/臃肿。
你要静态链接吗？您可能想比较使用 c++ 与 c 的静态虚拟应用程序。这可能会导致您改为考虑 C。另一方面，如果您能够在内存需求范围内构建 C++ 应用程序，那就去做吧。
恕我直言，总的来说，在嵌入式应用程序中，我喜欢了解正在发生的一切。谁在使用内存/系统资源，多少以及为什么？他们什么时候释放他们？
在为具有 X 数量的资源、cpu、内存等的目标进行开发时。我尽量保持在使用这些资源的较低端，因为您永远不知道未来会出现什么需求，因此您需要向项目中添加更多代码“应该”是一个简单的小应用程序，但最终变得更大。
C 在可移植性方面获胜——因为它在语言规范中不那么模棱两可；因此在不同的编译器等方面提供了更好的可移植性和灵活性（减少了麻烦）。
如果您不打算利用 C++ 功能来满足需求，那么请使用 C。
我的选择通常由我们决定使用的 C 库决定，它是根据设备需要做什么来选择的。所以，9/10 次.. 它最终是 uclibc 或 newlib 和 C。我们使用的内核对此也有很大的影响，或者如果我们正在编写自己的内核。
它也是共同点的选择。大多数优秀的 C 程序员在使用 C++ 时都没有问题（尽管许多人在使用 C++ 的过程中一直抱怨）.. 但我还没有发现相反的情况（根据我的经验）。
在我们正在处理的一个项目中（涉及一个全新的内核），大多数事情都是用 C 完成的，但是一个小的网络堆栈是用 C++ 实现的，因为使用 C++ 实现网络更容易而且问题更少。
最终结果是，该设备要么工作并通过验收测试，要么不会。如果您可以使用语言 z 在 xx 堆栈和 yy 堆约束中实现 foo，那就去做吧，使用任何让您更有效率的东西。
我个人的偏好是 C，因为：
是的，我对 C++ 很满意，但我对它的了解不如标准 C。
现在，如果您可以反过来说，那么，使用您所知道的 :) 如果它有效，通过测试等.. 有什么问题？
你有多少 ROM/FLASH？
4kB 的 RAM 仍然意味着有数百 KB 的 FLASH 来存储实际代码和静态数据。这种大小的 RAM 往往仅用于变量，如果您对这些变量小心，您可以将相当大的程序在代码行方面放入内存中。
然而，由于对象的运行时构造规则，C++ 倾向于使将代码和数据放入 FLASH 中更加困难。在 C 中，常量结构可以很容易地放入 FLASH 内存并作为硬件常量对象访问。在 C++ 中，常量对象需要编译器在编译时评估构造函数，我认为这仍然超出了 C++ 编译器的能力（理论上，你可以做到，但实际上很难做到） .
因此，在“小型 RAM”、“大型 FLASH”这种环境中，我随时都会使用 C。请注意，C99 是一个很好的中间选择，它具有非基于类的代码的大部分优秀 C++ 特性。
只想说没有“无限”资源的系统。这个世界上的一切都是有限的，每个应用程序都应该考虑资源使用，无论是 ASM、C、JAVA 还是 JavaScript。分配几 Mbs “只是为了确定” 的假人使 iPhone 7、Pixel 和其他设备非常笨拙。无论您有 4kb 还是 40 Gb。
但从另一方面反对资源浪费——是需要时间来节省那些资源。如果用 C 语言编写一个简单的东西来节省几个滴答声和几个字节，而不是使用已经实现、测试和分发的 C++ 需要多花 1 周的时间。何苦？这就像购买一个 USB 集线器。是的，你可以自己做，但会更好吗？更可靠？如果你计算时间更便宜？
只是一个侧面的想法 - 即使您的插座的电源也不是无限的。尝试研究它的来源，你会发现它主要来自燃烧的东西。能量和物质定律仍然有效：没有物质或能量出现或消失，而是在变化。
一般来说没有。C++ 是 C 的超级集合。对于新项目尤其如此。
您在避免 C++ 构造方面走在正确的轨道上，这些构造在 cpu 时间和内存占用方面可能很昂贵。
请注意，像多态这样的一些东西可能非常有价值——它们本质上是函数指针。如果您发现需要它们，请明智地使用它们。
此外，良好的（精心设计的）异常处理可以使您的嵌入式应用程序比处理带有传统错误代码的应用程序更可靠。
对于内存分配问题，我可以推荐使用 Quantum Platform 及其状态机方法，因为它会在初始化时分配您需要的所有内容。它还有助于缓解争用问题。
该产品可在 C 和 C++ 上运行。
有人说 C 编译器可以生成更高效的代码，因为它们不必支持高级 C++ 特性，因此可以更积极地进行优化。
当然，在这种情况下，您可能希望对两个特定的编译器进行测试。
恕我直言，选择 C 的唯一原因是，如果您的平台的 C++ 编译器状态不佳（错误、优化不佳等）。
您在 C99 中有内联。也许你喜欢 ctors，但让 dtors 正确的业务可能会很混乱。如果剩下的不使用 C 的唯一原因是命名空间，我真的会坚持使用 C89。这是因为您可能希望将其移植到稍微不同的嵌入式平台。您稍后可能会开始使用 C++ 编写相同的代码。但是请注意以下内容，其中 C++ 不是 C 的超集。我知道您说您有一个 C89 编译器，但是无论如何都要将 C++ 与 C99 进行比较，因为例如第一项对于自 K&R 以来的任何 C 都是正确的。
sizeof 'a' > 1 在 C 中，而不是在 C++ 中。在 C 中，您有 VLA 可变长度数组。示例：func(int i){int a[i]。在 C 中，您有 VAM 变量数组成员。示例：struct{int b;int m[];}。
这取决于编译器。
并不是所有的嵌入式编译器都实现了所有的 C++，即使他们实现了，它们也可能不擅长避免代码膨胀（这对于模板来说总是一个风险）。使用一些较小的程序对其进行测试，看看是否遇到任何问题。
但是给定一个好的编译器，不，没有理由不使用 C++。
针对问题的不同方面的不同答案帖子：
“malloc”
之前的一些回复对此进行了相当多的讨论。为什么你甚至认为这个电话存在？对于一个真正的小平台，malloc 往往不可用，或者绝对是可选的。当您的系统底部有一个 RTOS 时，实现动态内存分配往往是有意义的——但在那之前，这纯粹是危险的。
没有它你可以走得很远。想想那些甚至没有适当的局部变量堆栈的旧 FORTRAN 程序......
全球有许多不同的控制器制造商，当您查看他们的设计和需要用于配置的指令集时，您可能会遇到很多麻烦。汇编语言的主要缺点是依赖于机器/架构。对于开发人员来说，为了完成不同控制器的编码而将所有说明都牢记在心，这确实是一个巨大的要求。这就是为什么 C 在嵌入式开发中变得更受欢迎的原因，因为 C 足够高级，可以从依赖于硬件的细节中抽象出算法和数据结构，使源代码可跨各种目标硬件、体系结构独立的语言移植，并且非常容易转换和维护代码。但我们确实看到了一些高级语言（面向对象），如 C、C++、Python、Java 等。
我推荐带有限制和注释的 C++。
上市时间和可维护性。C++ 开发更加简单快捷。因此，如果您处于设计阶段，请选择一个足以使用 C++ 的控制器。（请注意，一些大批量市场需要尽可能低的成本，而您无法做出此选择。）
速度。C 可以比 C++ 更快，但请确保速度增益不大。因此，您可以使用 C++。开发您的算法，测试它们，并仅在需要时使它们更快（！）。使用分析器，指出瓶颈并以外部“C”方式重写它们，以实现 C 速度。（如果在 ASM 中实现该部分仍然很慢）
二进制大小。C ++代码更大，但这是一个很好的答案，可以说明细节。无论是使用 C 编译器还是 C++ 编译器编译，给定 C 代码的编译二进制文件的大小都是相同的。“可执行文件的大小几乎与语言无关，而与项目中包含的库有关。” 使用 C++ 但避免使用高级功能，如streams, string, new,virtual函数等。由于大小限制（基于此答案） ，请在将它们放入最终代码之前查看所有库函数
在这样一个有限的系统上。就去汇编吧。让您完全控制各个方面，并且不会产生任何开销。
可能也快得多，因为许多嵌入式编译器不是最好的优化器（特别是如果将它与最先进的编译器进行比较，比如我们的桌面编译器（英特尔、Visual Studio 等））
“是的，是的……但是 c 是可重复使用的并且……”。在这样一个有限的系统上，您可能不会在不同的系统上重用大部分代码。在同一系统上，汇编器同样可重用。