單片機編程最早是彙編，然後從彙編轉為c語言，那麼，c++會不會替代c語言來進行單片機編程 ？
希望不懂c++的不要噴
1，高級語言已經應用在MCU上面了arduino採用processing語言mdk的編譯器支持C++語法甚至有人在ARM Cortex-M3架構的mcu上實現了lua解釋器（lua是ANSI C寫的）
2，底層驅動用c或者彙編來寫
業務邏輯用cpp3，原子操作和中斷操作用c/彙編4，C++編譯器做了很多小動作，生成的代碼的可預測性降低，舉個韋大答案裡面的例子，str1=str2+"hello"+str3;天知道這句話裡面做了幾次拷貝幾次構造。對於很多工控設備，低的代碼可預測性==高風險5，以mcu的工作量，不是非得C++才能完成業務邏輯6，mcu的那一點flash容量恐怕連最簡單的C++的stl/boost庫都放不下，而cpp的很多高階特性是依賴於這些庫實現的。沒有強大的運行時進一步降低了C++在mcu領域的性價比7，彙編到c語言的變化是語法上進一步簡明、模式化的過程，c到cpp（指c和cpp公共特性之外的那一部分語法特性，你要是拿cpp干c的活兒當我沒說）是編程思想的轉變，這兩種變化完全不同以上，不會。--再補充一點吧。現在比較大的問題是晶元廠商和OS對C++的支持。大廠比如TI，可以為推廣自己的MCU特地搞一整個toolchain，專門做嵌入式IDE的廠商比如IAR可以做編譯器，ARM可以為所有採用CM0/3/4/7的MCU提供ARM C/C++ toolchain，但是那些採用非主流指令集的小廠呢？台灣的OTP晶元呢？即便是用MIPS的PIC32，他的C++編譯器能用？C++11搞了個lambda函數你姿不姿詞？C++14又搞了個泛型lambda和類型推斷你要不要繼續資詞？A廠商資詞了，B廠商姿不姿詞？項目1用了A廠商晶元C++用得很爽，項目2要求低功耗換B廠商發現C++不能用了，legacy code全部重新寫一遍？引用Linus的話：
In fact,in Linux we did try C++ once already,back in 1992.
It sucks.Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA！
C++不可代替C。
但是單片機這個場景太模糊了，基本上沒有辦法斷言說單片機就沒法用C++什麼的。
C++的問題就在於編譯器做的小動作太多了，乾的事情太多了，編譯後的結果和源代碼的關係可以說基本沒啥關係，所以很多場景下是不能代替C語言的。至少在51上沒啥希望。
月經題。。
c++並不是不可以。老提51也沒意思，現在的mcu比如Cortex M7架構都做到300MHZ+了，51不能用c++，M7就不能了嗎。
說c就滿足需求或者只有c才能滿足需求也太扯淡了，Embedded的範圍那麼管，mcu的應用領域有很多，對運行效率要求稍低，代碼量大，對oop有需求的場景多了去了c++在mcu編程領域裡還只是探索階段而已，一個使用c++的例子就是最近非常潮的mbed了，mbedmicro/mbed · GitHub
但使用c++的話，還有一些小問題，比如
- 全局的類變數在什麼時候調用其構造函數，什麼時候析構
- new，delete依賴內存管理
也就是說，為了使用c++高級於c的那些特性，必須要實現很多stub函數，導致資源佔用變多，開發難度增大。
c++的模板等特性會導致代碼體積增大
c++的stl並不適合嵌入式領域
以c常用的鏈表為例，用鏈表的目的是什麼？省空間還是省時間？ - 馮東的回答，而stl下的list就做不到這些優點，還會在你不希望的場合進行delete等操作。個人感覺，c++畢竟有很多優勢應該會在未來的單片機領域和c共存，來滿足IoT，智能硬體這些新領域出現的新需求，只不過開發工具還需要進一步完善。arduino基本算是cpp，我一直覺得會被取代，但不一定是cpp，這種取代應該是基於編譯器的進步
我以前在群里和別人撕逼過的一個問題。大家:嵌入式可以用C++開發嗎？撕逼者:可以。我:我是指不帶操作系統的嵌入式——裸機，可以嗎？一般裸機沒有C++運行環境哦撕逼者:可以的，編譯器可以編譯就可以。不需要什麼運行環境…我:那可以使用STL開發嗎，那個需要環境支持哦！撕逼者:沒有STL呢！誰說支持C++就一定要STL啊！我:……………我:你說不要運行環境，STL,智能指針，多態這些特性能支持嗎？撕逼者:那些又用不上………我:……………
————————分割線————
這個問題討論起來最蛋疼的，就是撇開操作系統，運行環境和語言完整性來討論這個問題。。是不是只要編譯器支持class這個關鍵字就算支持C++了，那gcc編譯器支持inline，這個也是C++的關鍵字，那不是也支持了。。。只是一個支持C語言以及部分C++的擴張特性的編譯器，就算支持C++嗎？C是C++的一個子集，C和其它部分特性合起來，也只是C++的一個子集，你說支持就支持了。所以繼續撕逼吧！本人單片機工作者（說好聽點吧，嵌入式研發員），用c開發單片機，用c++寫上位機。目前感覺，應該是不可能。首先單片機很多的編譯器都比較舊，只支持C，但編譯出來的C效率很高，但c++，至少沒有C效率高，這就意味著很少會有人把這些編譯器重寫一遍，況且C++很多的規則，而且太多的庫，不方便調試。另外，單片機領域的工作思維，其實是和C的編程思維差不多，先分析過程，你用C++做，我剛學不久，面向對象的思維還沒完全理解，再用這種半吊子的思維去開發單片機，那不管是從開發效率，還是運行效率上，肯定要慢。因為開發單片機的人，100%是從C和彙編中的一門來入門的，這註定搞單片機的大部分的思維方式是面向過程，一但確定下來，想要改很難了，我舅舅從C轉java，思維的改變用了好幾年……其實我的看法是，以後可能會取代部分，但不會完全取代，而且入門的基礎語言肯定還是C，只有用C才會真正理解單片機。用C++開發，只會存在於那些不太需要關注flash，ram的大小和對時間要求很低的地方。
主要看你的應用範圍。
1. c++有些關鍵詞的意義變了，const是常量，c語言中const是只讀。2.c++編譯器做的工作太多了，最後轉換為彙編時加了很多代碼，比如吧，構造函數初始化，析構。
使用單片機做一些底層，高實時的應用，我是希望完全控制mcu的行為的，不希望多出來的行為和代碼。c語言相比，簡直就是彙編的直接翻譯。
當然，很多人想用c++做mcu可能只是希望用它的封裝能力。
除了用一些封裝好的cpp的庫以外，並沒有什麼卵用。需要嵌入式負責的業務邏輯一般不會太複雜，如果真的需要複雜請發到上位機去，或者直接用工控機。上位機各種腳本語言亂飛，下層老老實實做自己的事就好。這個和企業是一樣的。
KEIL MDK 和 IAR for ARM/MSP430已經支持 c++。。。
正在轉過去……不用C++一些複雜的特性，效率差別不大的！以前amobbs論壇里有個壇友做過測試！同樣的功能，C++跟C差別不大，編譯器又不是吃素的！github有個項目 micropython 在 stm32f103上跑的溜溜的，看名字就知道了，感興趣去看看！
我覺得cpp可以跑，有些晶元都可以跑C#了，主要是考慮應用場合。不考慮成本，快速開發，拿來跑跑就行。但對於一些利潤很低的產品，用個便宜的片子很重要，便宜的晶元資源少，那麼跑c語言就合適，當然彙編更好，一般這個成本差別小，那就選擇開發成本低的。還有就是如果時實要求高的，cpp不行的，還是彙編靠譜。cpp耗資源太多，對成本控制不好。不過晚幾年如果256內存絕跡了，最低配都是K級別的，就會選cpp了。
既然有人問C#，我沒有用過
NETMF for STM32http://www.st.com/content/ccc/resource/technical/document/user_manual/d4/f9/3c/5f/ff/e0/45/48/DM00096190.pdf/files/DM00096190.pdf/jcr:content/translations/en.DM00096190.pdf還有什麼想知道的，請自行google另外再給你安利一個JavaScript語言寫單片機你可以去問他Roy Li，看看能不能送樣品，記得替我要一個。我已經在cortex-m上完全使用c++很久了，我肯定我再也不會回到c了。
用C編程還需要volitale保證代碼不會被編譯器搞亂，C艹編譯器會把代碼搞成什麼樣只有天知道
單片機編程基本屬於邏輯控制 代碼工程實在想像不出會有多大 每塊晶元或者設備邏輯只需要寫好各自的控制函數就行 用c++說明是想用面向對象思維解決問題 說明你的單片機系統已經非常複雜了 如果還是單純的硬體控制 c++面向對象方式怎麼套都覺得浪費 還有c語言之所以能代替彙編 是因為c的編程思維極為接近彙編 性能差不太多 而且又比彙編簡單的多 但是c++編程思維明顯不一樣 這讓和晶元打交道的人相當於做了二次翻譯一樣 實在想像不出來
C 多年來跟C++幹了好多戰爭，在C語言上面最瘋狂的支持者就是Linux 之父 Linus，他用c寫了git，現在一樣用得好好的，很多開源項目也都是使用C語言來做，非常贊！
回到問題的開始，C++會不會代替C成為，單片機的編程語言呢？
答案很明確，No，無論系統在負責，底層部分還是用C來寫比較好。
但C++也是自己的用途，我曾經呆過的一家公司，用C++來寫GUI，跑在單片機上面，UI的代碼相當的簡潔！C++，更適合來搭建框架。C，更適合寫API（也可以搭框架，看你的能力了，C的架構里很多都是用動態庫）1.對於大多控制系統而言，面向過程的概念用起來更加順手。既然這樣，大家就沒必要用C++了，不然就是在用C++寫C2.關鍵是現在很多編譯器不太支持C++的特性啊，什麼重載，面向對象都木用啊！！雖然編程效率會提高但是不能用啊！！！
做可以做，但是Cpp必須閹割，也就是只是C with class了，想用string？不存在的。不敢用的。例如汽車行業中的ISO26262.這就完全限制了heap的使用。
價格0.3元，存儲空間1K ram 64byte 的MCU 的應用大把多。 這樣的資源C都夠嗆，大多彙編。
所以，MCU這個類本身不會被什麼語言大統一。語言這個工具應該是根據軟體規模，應用環境選擇合適的吧。個人認為僅用基本的OOP特性的話，C++更適合嵌入式開發，尤其是涉及大量外設的情況。
其實Arduino已經這樣做了，雖然它叫Processing，但分明就是去掉STL的C++。
把UART IIC等資源封裝成類，加速度計等外設也封裝成類，把數據和操作（函數）封裝在一起，簡直太爽了。比c裡面用struct保存各個外設的狀態和數據，舒服多了。使用第三方庫也很方便。但是Arduino也有混亂的地方，尤其是牽扯中斷/定時器的時候，不同的庫經常衝突。要想找到既易用又不失靈活性的方法，恐怕要實現一個統一的框架來管理各種資源，這差不多像一個操作系統了。個人認為，如果僅用基本的oop特性，比如類，捨棄stl和其他不必要的功能，這樣一個精簡的C++很適合處理大量外部設備的情況，適合單片機的應用。說說c跟彙編吧目前在單片機編程時是有很多人用C，因為c相對彙編來說更有可讀性，更容易維護，但並不能說c取代了彙編，目前還是並存的，只是應用的場合有所不同，有時候甚至還混用。用c固然可以縮短編程的時間，但是它也有其弱點，那就是效率（相對於彙編）低了不少，這就導致編譯器編譯為彙編時需要用更多的指令來描述這段程序，就需要佔用更多的ROM空間。對於比較不那麼計較成本的產品來說影響不是很大，但是對於一些比如小家電或者玩具之類的對成本比較敏感的產品來說多了一毛也許就競爭不過別人了，所以能省一點是一點。由於c語言寫完還是要通過編譯器編譯為彙編，效率也不及彙編，而且就算對c程序進行優化可以提高不少效率，但是優化的結果是經常掉東西，這時候就需要彙編登場了。現在有些廠商的晶元便宜，意味著空間小，比如合泰的 MCU，而小家電雖然功能不是特別多，但是完成一定功能所需的動作常常是很多的，所以在這方面彙編還是很吃香的，就像我主管彙編很溜而c不熟。彙編還有個好處就是指令周期固定，對於需要有較精準延時等等場合是很有用的，所以有時會c語言嵌彙編單片機的啟動文件一般也用彙編寫的，為了保證初始化的準確性說了這麼多就是想說c語言跟彙編其實是互補的，用在不同場合，而目前C語言用得比較廣C艹不熟，不做評論
推薦閱讀：
※計算器為什麼能實現保留根式、分數或含π的結果的功能？
※程序員得痔瘡算工傷嗎？
※C語言中連續定義兩個變數，為什麼地址是這樣的？
※為什麼單機遊戲的啟動時間一般都比較長？有沒有辦法進行縮短？
※python2.7.9 安裝錯誤 there is a problem with...該怎麼解決？