這是知乎嵌入式領(lǐng)域的一個熱門話題,原文鏈接:
https://www.zhihu.com/question/374663834
幾個高贊回答:
idea4good:
先說結(jié)論:
-
嵌入式、單片機(jī)里面C++非常好使; -
C with class用來作大部分開發(fā)是完全可以勝任,如果用的好,能明顯改善你的代碼質(zhì)量(嵌入式領(lǐng)域,個人不鼓勵STL和模板,這個后面再說)。
只有5千行代碼的GuiLite是嵌入式、單片機(jī)中常用的GUI框架;它就是C++編寫,在GitHub有4.8K star,在Gitee有2K star。可能你覺得5千行能做什么?
它不僅可以作常規(guī)的界面元素,還能在單片機(jī)平臺上進(jìn)行3D操作、可以與網(wǎng)頁結(jié)合,把界面效果用網(wǎng)頁的形勢表現(xiàn)出來,當(dāng)然也支持VR特效、最近還與FFmpeg集成,可以無依賴的支持視頻播放。多說無益,有圖為證:
這里不是說GuiLite多強(qiáng),而是想說明C++語言的魅力,如果沒有使用C++語言,而用C的的話,至少需要幾萬行才能實(shí)現(xiàn)相同的效果;還記得著名的愛因斯坦bug方程嗎?代碼多一點(diǎn)點(diǎn),bug數(shù)量就會顯著增加。
其實(shí)GuiLite就是典型的C with Class;相信很多同學(xué)覺得這很低級,但這正是C++語言發(fā)明的初心。這種特性讓你完全告別的了函數(shù)指針;當(dāng)然很多C的高手,就是用函數(shù)指針實(shí)現(xiàn)了C++的所有特性。
首先為高手點(diǎn)贊,但作為普通韭菜的我們要明白它的代價(jià)就是一大堆函數(shù)指針;只要函數(shù)指針的大量存在,代碼的可讀性就大大降低,而C with Class就能用最優(yōu)雅的方式消滅所有的函數(shù)指針,雖然你覺得它很low,但它就能讓你的代碼量大大縮小;而且它對編譯器的支持極好,任何單片機(jī)編譯器都能支持這種簡單的C++特性。
如果你還讀過Linux的虛擬文件系統(tǒng)代碼,請問是什么反復(fù)打斷你領(lǐng)會代碼含義?答案是函數(shù)指針,為了實(shí)現(xiàn)對多文件系統(tǒng)的支持,Linus可是在拼命的往代碼里面使用函數(shù)指針。而如果選擇用繼承,虛函數(shù)來實(shí)現(xiàn),其代碼就可以大大簡化。
這就是用C實(shí)現(xiàn)派生,虛函數(shù)擴(kuò)展的代價(jià);你可能會說:Linus這種方式效率高呀!答案是:不存在;無論你如何在C語言層次做優(yōu)化,都沒發(fā)跟編譯器層次的優(yōu)化相提并論。
作為開發(fā)者,編程思想遠(yuǎn)遠(yuǎn)比語法糖重要的多。C with Class是編程思想的進(jìn)步,雖然在語法難度上面它不值一提。記住,我這里說的是編程思想,即使這么簡單地語法,現(xiàn)在還是被濫用了,完全不考慮實(shí)際需要,上來就是一個class,完全不顧及class發(fā)明者的初衷。class需要你在高level重整代碼結(jié)構(gòu),但你卻用它污染每一個細(xì)節(jié),每一行代碼。
還是那句話,用的好,5千行就能解決很多問題;用的不好,還不如不用,還是用你最擅長的語言去污染你的代碼吧,這樣污染的更有效率,對吧?
最后,STL,模板適合嵌入式嗎?個人覺得不大適合,首先這是對編譯器的極大挑戰(zhàn),windows,linux平臺不是問題,但在單片機(jī)環(huán)境可能存在兼容性的問題;另外,模板,STL對調(diào)試非常不友好,不太適合運(yùn)行成本(步驟)相對復(fù)雜的嵌入式、單片機(jī)開發(fā)環(huán)境。
STL,模板的發(fā)明初衷也不是為嵌入式,單片機(jī)準(zhǔn)備的;所以,強(qiáng)行使用,會給你帶來很多麻煩。STL,模板的最佳使用環(huán)境是大型“游戲”。
這套東西是典型用空間換時間的產(chǎn)物,很多牛逼的游戲所需的cpu,內(nèi)存資源極少,就是他們的功勞,但代價(jià)是你的代碼會比較龐大,沒有1T的硬盤,就不要玩游戲了吧~~~STL,模板為什么能在游戲行業(yè)里面如魚得水呢?
首先,運(yùn)行效率很高,這里不再贅述;其次,則是游戲的重復(fù)性太高,大家回憶一下,DOTA,英雄聯(lián)盟,王者榮耀在玩法上面是不是很相近呢?
正是因?yàn)橄嗨菩蕴?,代碼重用就顯得非常必要,否則游戲工業(yè)化的效率就很低,現(xiàn)在之所以半年就能出一款大型游戲,我說這是STL、模板的功勞,你信嗎?我說是游戲引擎的功勞,你信嗎?我說游戲引擎跟STL、模板是你中有我,我中有你,你信嗎?
總結(jié)一下,C++編程思想對嵌入式開發(fā)者很有幫助,直接效果就是能大幅度降低你的代碼量和邏輯復(fù)雜度;STL,模板原則不適合大部分嵌入式使用環(huán)境,因?yàn)榍度胧杰浖奶厥庑酝^通用性,代碼復(fù)用的需求不強(qiáng),但只要你知道它們是為什么而生的,就會為它們選擇合適的使用環(huán)境。
聽心跳的聲音:
單片機(jī)的主流編譯語言可預(yù)見的長期仍然是C和少量匯編的結(jié)合體,而嵌入式Linux領(lǐng)域的未來在我看來更傾向于多語言范式的混合應(yīng)用編程,內(nèi)核模塊使用C,應(yīng)用層邏輯使用C++, Python, nodejs的混合編程,而界面的話使用java和QT/C++,下面說原因。
在單片機(jī)領(lǐng)域C++不太流行既有歷史原因,也有工業(yè)界的需求,對于單片機(jī)是從51發(fā)展到現(xiàn)在,主流的flash容量仍然在64KB~256KB左右,目前的容量限制注定了C++中的模板,泛型編程和STL等很難被運(yùn)用到開發(fā)中,但如果不使用這些,只使用支持class的C++,在C語言是有結(jié)構(gòu)體+函數(shù)指針可以替代的情況下,從C換成C++并沒有迫切的需求,而python和js的推廣困難,也有著類似的理由,此外在加上調(diào)試?yán)щy。
不過對于rust,這個理由是不存在的,但是因?yàn)闅v史的慣性,目前行業(yè)內(nèi)無論大小公司,都大量的遺留和正在做的都是C語言項(xiàng)目(包含原廠的方案),替換成rust就是商業(yè)成本問題,而不是語言問題(在我看來rust語言層面優(yōu)于C太多),所以rust熱愛者們應(yīng)該是多去為各主流廠商平臺提供開源項(xiàng)目(具體項(xiàng)目,不是移植跑個hello world就完事了, 能跑和能用在產(chǎn)品中是兩個概念),而不是呼吁語法層面多優(yōu)秀。
另外單片機(jī)優(yōu)勢不僅僅是實(shí)時可控,而是價(jià)格便宜,對于出貨量十萬甚至上百萬的設(shè)備,flash容量也是可觀的成本,所以工業(yè)界更希望是用最小的成本做最多的事,從這方面來說,C是比C++,python, js有明顯優(yōu)勢的。
在嵌入式Linux領(lǐng)域, C++絕對是應(yīng)用層主力之一,QT/C++雖然目前因?yàn)樾酒阅艿奶嵘?,逐漸被Android/Java所替代,但仍然在醫(yī)療,工控,車載導(dǎo)航等領(lǐng)域占據(jù)主流地位,而且這也是目前C++的重要應(yīng)用領(lǐng)域之一,說嵌入式比較難,而C++也十分困難,所以嵌入式人員學(xué)習(xí)C++比較少是十分片面客觀的印象。
另外C++難的地方是移動語義,模板偏特化,lambda, ?模板元編程等知識,C++各種語法組合成的奇淫巧技如果不花大量時間去鉆研,看起來是猶如天書(很少有人例外),但對于工業(yè)界,特別是嵌入式類應(yīng)用來說,只使用STL封裝的vector,map以及算法等方便開發(fā),封裝些模板函數(shù)或者類幫助復(fù)用,很多時候C++11的新特性都用不全,說困難就有點(diǎn)夸大其詞了。
工業(yè)界的難點(diǎn)永遠(yuǎn)是如何把產(chǎn)品的需求轉(zhuǎn)換成具體的任務(wù)分解(滿足性能,成本和功能的平衡,同時能夠長期穩(wěn)定性),而不是使用何種語言來實(shí)現(xiàn)任務(wù),當(dāng)需求導(dǎo)向任意語言,無論是python,js,C++還是java,面向工資編程,只要有需求,總會有人會踏入這個方向,難度不是問題,需求和薪水才是問題。
pansz:
現(xiàn)實(shí)情況是:C++太難了,嵌入式人才本來就少,你還要能用C++且不出幺蛾子,那就更少。
所以用C確實(shí)是主流。因?yàn)镃程序員要求還是低些。
記得我當(dāng)初剛搞嵌入式的時候,系統(tǒng)連MMU都沒有,整個系統(tǒng)所有代碼全都在一個內(nèi)存空間,還得自己管理內(nèi)存池避免內(nèi)存碎片。隨便一個內(nèi)存訪問錯誤可以影響到完全不相干人的模塊的代碼。這種系統(tǒng)你敢用C++?
結(jié)論:如果你是自己一個人開發(fā)代碼,并且對自己的C++水平有信心,那么用C++當(dāng)然沒有問題。但是考慮到整體程序員群體的C++水平以及C語言水平,用C做嵌入式項(xiàng)目會更現(xiàn)實(shí)一些。
candy:
作為一個嵌入式十多年老手,可以說CPP太復(fù)雜,語言特性太多,實(shí)現(xiàn)一個功能能能用幾十個以上的方法,太多稀奇古怪的方法去實(shí)現(xiàn)一個功能,CPP特性復(fù)雜得沒有5年以上經(jīng)驗(yàn)別想用好。但一個項(xiàng)目組幾個人CPP能力不一致,用一些稀奇古怪的特性去實(shí)現(xiàn)一些功能,多個人之間就沒法維護(hù)了。
在調(diào)試的時候,面向?qū)ο蟮恼{(diào)試最好上圖形界面的工具才好調(diào)試,而嵌入式大多數(shù)時候是沒有這種調(diào)試工具的,CPP寫業(yè)務(wù),后期bug調(diào)試也會搞死你,CPP嵌入式調(diào)試比C復(fù)雜一個數(shù)量級以上。
第三點(diǎn),C語言特性雖然少,但完全夠用,實(shí)現(xiàn)一個功能方法不會很多,1年左右入門,3年老手,而CPP3年連CPP特性還沒搞清楚。C可以簡單用,也可以復(fù)雜用,C with class小cass,結(jié)構(gòu)體加指針輕松實(shí)現(xiàn),看看linux kernel, 看看內(nèi)核頭文件,結(jié)構(gòu)體,宏各種精妙用法,你就會發(fā)現(xiàn)CPP完全多余了,CPP死于復(fù)雜。有經(jīng)驗(yàn)的大公司團(tuán)隊(duì)使用CPP都是使用CPP的一個子集,只使用一部分特性。
CPP設(shè)計(jì)特性太多不是優(yōu)點(diǎn),而是缺點(diǎn),別看什么特性幾乎都支持,其實(shí)太多選擇其實(shí)就是沒有選擇。實(shí)現(xiàn)一個功能有且僅有一種方法才是一個好語言,例如python,go也不錯。
第四點(diǎn),產(chǎn)品應(yīng)用層其實(shí)重要的是業(yè)務(wù),各種復(fù)雜的業(yè)務(wù)邏輯,語言特性太多反而會混亂業(yè)務(wù)邏輯。C完全夠用,各種設(shè)計(jì)模式,C也可以實(shí)現(xiàn)。
能吸收內(nèi)核一些優(yōu)秀特性,例如內(nèi)核雙向鏈表,一些結(jié)構(gòu)體,宏,日志,內(nèi)存管理,線程管理,線程間進(jìn)程間通訊,各種鎖基本都需要C自己封裝套來用,這些東西學(xué)會了才能說用好了C。即使對于新手來說,不會這些高級C用法,有一個高級C也可以帶領(lǐng)一群低級剛?cè)腴T的寫一寫業(yè)務(wù)代碼。而一個高級CPP沒法帶領(lǐng)一群剛?cè)腴T的CPP初學(xué)者完成同樣的項(xiàng)目。
第五點(diǎn), 資源限制,效率限制,同樣的業(yè)務(wù)功能,C的內(nèi)存占用,速度高于CPP,這些東西CPP里面基本都有現(xiàn)成的,可是了體積大,依賴多,對于嵌入式環(huán)境來說太過于笨重了。就是說同樣的產(chǎn)品,使用C可以使用更低端的主控芯片,更小的內(nèi)存,產(chǎn)品bom成本比使用cpp低,產(chǎn)品競爭優(yōu)勢遠(yuǎn)高于使用cpp的。
免責(zé)聲明:本文來源網(wǎng)絡(luò),免費(fèi)傳達(dá)知識,版權(quán)歸原作者所有。如涉及作品版權(quán)問題,請聯(lián)系我進(jìn)行刪除。
猜你喜歡
wireshark抓包工具的使用及分析
記一個OLED編程中文顯示函數(shù)的坑(留意變量數(shù)據(jù)類型的范圍)
加好友,回暗號【嵌入式大雜燴】,進(jìn)微信群
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點(diǎn),不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!