C++在嵌入式中表现如何？

几个高赞回答：

idea4good：

先说结论：

嵌入式、单片机里面C++非常好使；

C with class用来作大部分开发是完全可以胜任，如果用的好，能明显改善你的代码质量（嵌入式领域，个人不鼓励STL和模板，这个后面再说）。

只有5千行代码的GuiLite是嵌入式、单片机中常用的GUI框架；它就是C++编写，在GitHub有4.8K star，在Gitee有2K star。可能你觉得5千行能做什么？ 它不仅可以作常规的界面元素，还能在单片机平台上进行3D操作、可以与网页结合，把界面效果用网页的形势表现出来，当然也支持VR特效、最近还与FFmpeg集成，可以无依赖的支持视频播放。多说无益，有图为证：

这里不是说GuiLite多强，而是想说明C++语言的魅力，如果没有使用C++语言，而用C的的话，至少需要几万行才能实现相同的效果；还记得著名的爱因斯坦bug方程吗？代码多一点点，bug数量就会显著增加。 其实GuiLite就是典型的C with Class；相信很多同学觉得这很低级，但这正是C++语言发明的初心。这种特性让你完全告别的了函数指针；当然很多C的高手，就是用函数指针实现了C++的所有特性。 首先为高手点赞，但作为普通韭菜的我们要明白它的代价就是一大堆函数指针；只要函数指针的大量存在，代码的可读性就大大降低，而C with Class就能用最优雅的方式消灭所有的函数指针，虽然你觉得它很low，但它就能让你的代码量大大缩小；而且它对编译器的支持极好，任何单片机编译器都能支持这种简单的C++特性。 如果你还读过Linux的虚拟文件系统代码，请问是什么反复打断你领会代码含义？答案是函数指针，为了实现对多文件系统的支持，Linus可是在拼命的往代码里面使用函数指针。而如果选择用继承，虚函数来实现，其代码就可以大大简化。 这就是用C实现派生，虚函数扩展的代价；你可能会说：Linus这种方式效率高呀！答案是：不存在；无论你如何在C语言层次做优化，都没发跟编译器层次的优化相提并论。 作为开发者，编程思想远远比语法糖重要的多。C with Class是编程思想的进步，虽然在语法难度上面它不值一提。记住，我这里说的是编程思想，即使这么简单地语法，现在还是被滥用了，完全不考虑实际需要，上来就是一个class，完全不顾及class发明者的初衷。class需要你在高level重整代码结构，但你却用它污染每一个细节，每一行代码。 还是那句话，用的好，5千行就能解决很多问题；用的不好，还不如不用，还是用你最擅长的语言去污染你的代码吧，这样污染的更有效率，对吧？ 最后，STL，模板适合嵌入式吗？个人觉得不大适合，首先这是对编译器的极大挑战，windows，linux平台不是问题，但在单片机环境可能存在兼容性的问题；另外，模板，STL对调试非常不友好，不太适合运行成本（步骤）相对复杂的嵌入式、单片机开发环境。 STL，模板的发明初衷也不是为嵌入式，单片机准备的；所以，强行使用，会给你带来很多麻烦。STL，模板的最佳使用环境是大型“游戏”。 这套东西是典型用空间换时间的产物，很多牛逼的游戏所需的cpu，内存资源极少，就是他们的功劳，但代价是你的代码会比较庞大，没有1T的硬盘，就不要玩游戏了吧~~~STL，模板为什么能在游戏行业里面如鱼得水呢？ 首先，运行效率很高，这里不再赘述；其次，则是游戏的重复性太高，大家回忆一下，DOTA，英雄联盟，王者荣耀在玩法上面是不是很相近呢？ 正是因为相似性太高，代码重用就显得非常必要，否则游戏工业化的效率就很低，现在之所以半年就能出一款大型游戏，我说这是STL、模板的功劳，你信吗？我说是游戏引擎的功劳，你信吗？我说游戏引擎跟STL、模板是你中有我，我中有你，你信吗？ 总结一下，C++编程思想对嵌入式开发者很有帮助，直接效果就是能大幅度降低你的代码量和逻辑复杂度；STL，模板原则不适合大部分嵌入式使用环境，因为嵌入式软件的特殊性往往超过通用性，代码复用的需求不强，但只要你知道它们是为什么而生的，就会为它们选择合适的使用环境。

听心跳的声音：

单片机的主流编译语言可预见的长期仍然是C和少量汇编的结合体，而嵌入式Linux领域的未来在我看来更倾向于多语言范式的混合应用编程，内核模块使用C，应用层逻辑使用C++, Python, nodejs的混合编程，而界面的话使用java和QT/C++，下面说原因。 在单片机领域C++不太流行既有历史原因，也有工业界的需求，对于单片机是从51发展到现在，主流的flash容量仍然在64KB~256KB左右，目前的容量限制注定了C++中的模板，泛型编程和STL等很难被运用到开发中，但如果不使用这些，只使用支持class的C++，在C语言是有结构体+函数指针可以替代的情况下，从C换成C++并没有迫切的需求，而python和js的推广困难，也有着类似的理由，此外在加上调试困难。 不过对于rust，这个理由是不存在的，但是因为历史的惯性，目前行业内无论大小公司，都大量的遗留和正在做的都是C语言项目(包含原厂的方案)，替换成rust就是商业成本问题，而不是语言问题(在我看来rust语言层面优于C太多)，所以rust热爱者们应该是多去为各主流厂商平台提供开源项目(具体项目，不是移植跑个hello world就完事了, 能跑和能用在产品中是两个概念)，而不是呼吁语法层面多优秀。 另外单片机优势不仅仅是实时可控，而是价格便宜，对于出货量十万甚至上百万的设备，flash容量也是可观的成本，所以工业界更希望是用最小的成本做最多的事，从这方面来说，C是比C++，python， js有明显优势的。 在嵌入式Linux领域, C++绝对是应用层主力之一，QT/C++虽然目前因为芯片性能的提升，逐渐被Android/Java所替代，但仍然在医疗，工控，车载导航等领域占据主流地位，而且这也是目前C++的重要应用领域之一，说嵌入式比较难，而C++也十分困难，所以嵌入式人员学习C++比较少是十分片面客观的印象。 另外C++难的地方是移动语义，模板偏特化，lambda, 模板元编程等知识，C++各种语法组合成的奇淫巧技如果不花大量时间去钻研，看起来是犹如天书(很少有人例外)，但对于工业界，特别是嵌入式类应用来说，只使用STL封装的vector，map以及算法等方便开发，封装些模板函数或者类帮助复用，很多时候C++11的新特性都用不全，说困难就有点夸大其词了。 工业界的难点永远是如何把产品的需求转换成具体的任务分解(满足性能，成本和功能的平衡，同时能够长期稳定性)，而不是使用何种语言来实现任务，当需求导向任意语言，无论是python，js，C++还是java，面向工资编程，只要有需求，总会有人会踏入这个方向，难度不是问题，需求和薪水才是问题。

pansz：

现实情况是：C++太难了，嵌入式人才本来就少，你还要能用C++且不出幺蛾子，那就更少。所以用C确实是主流。因为C程序员要求还是低些。 记得我当初刚搞嵌入式的时候，系统连MMU都没有，整个系统所有代码全都在一个内存空间，还得自己管理内存池避免内存碎片。随便一个内存访问错误可以影响到完全不相干人的模块的代码。这种系统你敢用C++？ 结论：如果你是自己一个人开发代码，并且对自己的C++水平有信心，那么用C++当然没有问题。但是考虑到整体程序员群体的C++水平以及C语言水平，用C做嵌入式项目会更现实一些。

candy：

第一点，作为一个嵌入式十多年老手，可以说CPP太复杂，语言特性太多，实现一个功能能能用几十个以上的方法，太多稀奇古怪的方法去实现一个功能，CPP特性复杂得没有5年以上经验别想用好。但一个项目组几个人CPP能力不一致，用一些稀奇古怪的特性去实现一些功能，多个人之间就没法维护了。 第二点，在调试的时候，面向对象的调试最好上图形界面的工具才好调试，而嵌入式大多数时候是没有这种调试工具的，CPP写业务，后期bug调试也会搞死你，CPP嵌入式调试比C复杂一个数量级以上。 第三点，C语言特性虽然少，但完全够用，实现一个功能方法不会很多，1年左右入门，3年老手，而CPP3年连CPP特性还没搞清楚。C可以简单用，也可以复杂用，C with class小cass，结构体加指针轻松实现，看看linux kernel， 看看内核头文件，结构体，宏各种精妙用法，你就会发现CPP完全多余了，CPP死于复杂。有经验的大公司团队使用CPP都是使用CPP的一个子集，只使用一部分特性。 CPP设计特性太多不是优点，而是缺点，别看什么特性几乎都支持，其实太多选择其实就是没有选择。实现一个功能有且仅有一种方法才是一个好语言，例如python，go也不错。 第四点，产品应用层其实重要的是业务，各种复杂的业务逻辑，语言特性太多反而会混乱业务逻辑。C完全够用，各种设计模式，C也可以实现。 能吸收内核一些优秀特性，例如内核双向链表，一些结构体，宏，日志，内存管理，线程管理，线程间进程间通讯，各种锁基本都需要C自己封装套来用，这些东西学会了才能说用好了C。即使对于新手来说，不会这些高级C用法，有一个高级C也可以带领一群低级刚入门的写一写业务代码。而一个高级CPP没法带领一群刚入门的CPP初学者完成同样的项目。 第五点，资源限制，效率限制，同样的业务功能，C的内存占用，速度高于CPP，这些东西CPP里面基本都有现成的，可是了体积大，依赖多，对于嵌入式环境来说太过于笨重了。就是说同样的产品，使用C可以使用更低端的主控芯片，更小的内存，产品bom成本比使用cpp低，产品竞争优势远高于使用cpp的。

责任编辑：lq