幾個高贊回答：

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的。