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

电子说

1.2w人已加入

描述

几个高赞回答:

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

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分