为什么C ++不能在嵌入式系统中替代C？

首先C ++可用于嵌入式系统。如果它可以代替C，那将是更长的讨论（我的意思是将现有项目从C转移到C ++ ）。

关于C ++有很多神话，但大多数都是不真实的。主要是因为一个神话，即C是C ++的子集或C ++是C的超集。从历史上讲确实如此，但是今天两种语言都有很大的不同，您不能将解决C方面的问题的方法应用于C ++程序，否则会造成灾难性的后果。这就是非常有经验的C程序员正在尝试从C ++语言开始做的-该项目最终以用C语言编写的具有类样式的代码结束。

实际上，C ++具有多种功能，可以使嵌入式系统上的代码比使用C语言编写的代码更小，更快。编译器提供的大量优化也有很大帮助。用C ++编写正确的代码要容易得多，并且在目标系统上使用C ++代码进行单元测试之前要容易得多。

但是准备在目标上运行C ++代码可能会非常痛苦，并且您需要真正了解他们在做什么的人员。您的所有工具链都需要进行相应的配置，并且广泛可用的默认设置仅适用于基于Linux的系统，而不适用于裸机，标准库的怪癖需要分类，否则在执行过程中会遇到模棱两可的问题。但是一旦完成，您就可以开始了。

另一个问题是，众所周知的实时操作系统对C ++的支持几乎为零-它需要一些时间才能被排序并在用C编写的OS和RTOS的项目抽象之间创建适当的层。在C ++中制作成熟的RTOS的尝试并没有真正成为主流。今天，对C ++ 14的多线程支持，甚至在C ++ 17中的扩展，都使其变得更加复杂。今天有人很好地解决了这个问题，最终可能会解决越来越多的C ++实现的不断增长的物联网市场的漏洞。

对于许多想在嵌入式系统中使用C ++进行冒险的人来说，障碍是编译器。如果您可以负担得起使用GCC的费用，那么大多数情况下您还是可以使用ARM（不是全部）和MIPS，但其他架构仅受商业产品支持。例如，IAR最近在其Workbench编译器中添加了对C ++ 14的支持，而当前批准的标准是C ++ 17，并且所有新的GCC和CLANG都支持它。

领取免费学习资料以及教程，请查看下方图片：