單片機為什麼還在用C語言編程?(C語言為什麼不合理地增加一點面向對象的特性)
編了一些單片機的C語言程序,感覺C語言還有許多需要改進的地方,比如隨處定義變數,比如結構體成員使用其他成員,比如結構體成員的封裝。RTthread中使用了一些方法使C語言能夠有面向對象的特徵,而單片機編程不使用C++的原因一般被認為是虛方法之類導致運算時間不可預料和資源佔用大之類的。許多面向對象的特性似乎並不會導致運算時間的增加和資源的浪費,為什麼沒有一種具有基本面向對象特性的語言完全取代C語言呢?單純的面向過程意義何在?
--------------------2014.2.10更新---------------------String答主所說的Embedded C++似乎就是符合我需求的語言,為什麼它沒有火呢?PS:你們知道C語言如果增加了類的概念會方便多少么?PS2:Embedded C++
單片機這麼小的硬體,上面的語言要做到看到源碼就能想到彙編長啥樣,C 是為數不多的選擇。
單片機產品的成本是非常敏感的。因此對於單片機開發來說,最重要的是在極其有限的ROM和RAM中實現最多產品的功能。或者反過來說,實現相同的產品功能,所需要的ROM和RAM越小越好,因為一般來說ROM/RAM越小單片機越便宜。C++的高級特性引起的代碼體積膨脹比C大得多,這一缺陷是致命的。以前有過Embedded C++,去掉了一些標準C++的複雜特性,但是用的人不多,因為單片機產品的業務邏輯一般沒那麼複雜,用C就綽綽有餘。我見過最苦逼的程序員,他做的是遙控器。他們的產品開發竟然由採購員主導。如果有一天採購員在市場上找到一款單片機的價格比現在用的便宜幾分錢,他們就會基於新的晶元重新開發產品。這種情況下你還有心情談面向對象嗎。
不光單片機,多片機也在用C語言編程呀。你這個問題給我的感覺就好像是:別人都不用C語言了,為什麼單片機還在用?我覺得跟你的意思更貼切的可能是:為什麼大家還用C語言編程 或者 為什麼很多單片機都只提供了C語言的開發環境?對於前者:語言這種東西就像口味一樣,是不好評價的啦。有人愛用。對於後者:成本低呀。一套C語言開發環境很好做的,而其它的語言依賴性強或是有複雜的運行時支持系統,提供起來簡直是要了親命呀……單片機這種便宜又不那麼標準化而且還比較弱的系統,提供那些複雜的開發環境沒有啥商業上的好處呀……
這個嘛,想用python和ruby和java又沒內存處理器又太慢,想用.net又嫌貴(M¥有wince或micro framework),所以只能用C/C++了,無奈面對單片機的C++編譯器又沒有一個靠譜的,所以就只能用C語言了。=========================題目經過不斷的修改意思竟然變了。不過其實原因還是一樣
面向對象想實現得好到滿足你們這些寫單片機的程序的尺寸潔癖和性能潔癖什麼的高級要求實在是太難了!
51,Arduino,到樹莓派都接觸過,嵌入式領域還是速度至上,而且還有很多人用彙編在寫,所以C已經很好了,而且許多能支持C++了
題主應該沒怎麼用過那種只有幾KB ROM的單片機,每個位元組的存儲都需要斤斤計較的時候,C語言都嫌臃腫。為啥不用大點的ROM?因為ROM也是要錢的啊,成本敏感的領域,幾毛錢都要算計。
C就是C,沒必要加上面向對象的特性,加上那不成C++了。用C語言也可以實現自己的對象系統的,而且可以根據系統需求的複雜程度隨心所欲的簡化。除了有C++,還有C--呢。Mac OSX系統內核的驅動就是用一種簡化的C++來編寫的。
面向對象是編程思想,而不是編程語言的特質。誠然有些語言更直觀能實現面向對象的編程,但c語言未必就不可以。
你回顧一下各大論壇大家對STM32用ST庫開發還是直接操作寄存器開發都能爭的熱火朝天,很多人覺著用庫開發效率太低浪費資源。
沒錯,浪費資源。相信樓主也經常聽到這個詞兒。這群用8051甚至6502過來的窮慣了用ST官方庫都覺著奢侈的愛好者和工程師哪捨得用資源開銷更大的面向對象語言啊。P.S. 題主搞RTT的么? 我也想入門這個啊,翻了翻。還沒決定是專註學uC還是RTT。
單就語言層面來說,支持面向對象風格的C語言不是不可能,有人已經探討過。比如:
- http://ooc-coding.sourceforge.net/
- http://www.cs.rit.edu/~ats/books/ooc.pdf
我本身不從事單片機的開發,但是語言的發展總有其歷史的因素。C語言足夠滿足發展需求的時候,當大量的基於C語言的單片機開發已經形成行業慣例和規模時,強行轉換成另外一種語言很多時候得不償失。從另外一個方面說,C語言本身縱然有很多的缺點,但是這些「缺點」在很多時候也是它的「優點」。要控制採用C語言編寫的軟體的質量,需要更加有效的力度和編程風格。
有時都要用彙編…片上資源極其極其有限。甚至做乘法時都要用移位來做,都不用c默認的乘法,就是為了省資源。面向對象太費資源了。第一次看到STM32的官方庫時,竟然在想,這得浪費我多少時鐘啊!
移位乘法:因為在寄存器里的數都是二進位的,所以乘以2:左移一位;乘以4左移兩位;乘以8左移三位……依此類推對於STM32還有430甚至是DSP,都有人對用官方庫還是直接操作寄存器哪個比較省資源吵得天翻地覆……你還指望用C++嗎……底層的程序要求其實沒有桌面級那麼多花花腸子,C語言也就足夠了另外,底層的程序時不時都還要改寫成彙編來追求效率,讓這幫有性能潔癖的人用C++簡直會要了他的老命的
操作系統都用C!!一單片機就別嚷著叫要OO了,沒讓你完全用彙編就謝天謝地了!
為什麼要取代C?想不出一個足夠重要的理由,你要的「改進」都是語法糖. 如果你函數寫長了, 在函數中間定義一些變數了, 請考慮寫一個子函數.
為什麼要使用面向對象/封裝?管理代碼的複雜性。單片機打死就一萬幾千行代碼,沒有那麼複雜。要是複雜了就應該考慮使用別的平台。。單片機的開發和桌面應用開發真的很不一樣: 誰在桌面應用考慮過省電的? 即使你考慮過, 也輪不到你控制, 還有操作系統和一百幾十個後台程序在跑. 單片機要保證響應時間, 能耗, stack使用情況, 硬體限制, 很難兼顧怎樣寫得漂亮一些了.. 最多給長一點的函數名字和注釋, 這樣會不會好一些?
參見: 面向對象是個騙局?!如此理解面向對象編程C語言的流行程度不錯, 並且提供的抽象層次對於做一些片上的中/小型系統來說也勉強夠用; 一個更現實的問題是C的編譯器還是相對容易做的. 而目前我們遇到的情況是現在自己擼一套ISA的晶元廠商連一個靠譜的C編譯器都做不出來, 你還指望用更複雜的語言特性能在上面寫出多靠譜的程序?
(某個target到某RISC機器的某C編譯器在開-O2時竟然會把自動變數分配到r0(一個read出的值總為0的寄存器)上, 經常代碼寫著寫著再編譯就飛出一大片藍色的assembler warning, 去他媽的.因為大多數語言的解釋器/編譯器都是c寫的。。。
第一點,單片機資源不夠。單片機上普遍沒有我們桌面系統,甚至手機系統的資源高,存儲程序的空間也有限,C++帶來的編譯後附加信息太多,吃ROM,而且並不是必須的,單片機講的就是執行效率,所以人能做的,就不要交給單片機做。第二點要注意的是單片機未必編譯成x86,很多單片機指令集是定製的,因此即使大家看到的都是C,但是後台編譯出來的代碼是不同的,不是像我們搞一個gcc就能用,所以編譯器就是定做的嘍,你改成C++,編譯器重製上的工作量就是個問題。另外C++語法量還是蠻大的,現在這些C都不是完全版本的C語法,還有不少地方有限制,你再加個C++。。。
其實想用c++是可以的,avr-gcc和arm-none-eabi-gcc都早就提供了g++。
不過結果很可能是寫完了發現rom不夠用,下載不了。甚至用於mcu的python都有了,micropython,不過在幾十k flash的小mcu上基本別想用。上面有人舉了*duino的例子。其實這還有個更極端的:9.5成新HP39GS圖形全國數理化函數計算器SAT/AP考試專用計算器-淘寶網這東西裡面是個75M的ARM9,但是。。。裡面跑了個模擬器,模擬4位的HP saturn處理器。可能不太貼切,不過看到這個問題就這個感覺。標準51單片機就128位元組內存,能裝多少對象?
51單片機RAM 256B 題主你感受一下
推薦閱讀:
※想轉行做程序員應該考哪些證?
※C++ 編程中是否可以使用Objective C動輒幾十個字元的變數/函數命名方法?
※如何寫出優雅的代碼?
※如何理解漢諾塔的遞歸?
※為什麼近幾年浙江省信息學競賽這麼厲害?