十多年前，關(guān)于C 何時(shí)最終超越C并成為占主導地位的嵌入式系統編程語(yǔ)言，人們一直在爭論和期待。直到今天，C仍然是主導語(yǔ)言。鑒于微控制器硬件的進(jìn)步，更重要的是，工具鏈和現在可用的優(yōu)化，現在可能是使用C 的時(shí)候了。以下是嵌入式開(kāi)發(fā)人員應該開(kāi)始考慮在其嵌入式系統中使用C 的幾個(gè)原因。

原因 1 – 使用現代面向對象的編程技術(shù)

C編程語(yǔ)言是近50年前發(fā)明的一種過(guò)程語(yǔ)言，它是一門(mén)很棒的語(yǔ)言，但它缺乏現代編程語(yǔ)言所擁有的一切，例如

? 封裝

? 繼承

? 多態(tài)性

C開(kāi)發(fā)人員有時(shí)可以模擬這些基本的面向對象的特性，但它總是被迫的并且需要更多的努力?，F代語(yǔ)言自然會(huì )使用這些技術(shù)，如果使用得當，可以提高代碼的可讀性、重用性和可移植性。在當今復雜的系統中，使用可以從一個(gè)應用程序重用到下一個(gè)應用程序的類(lèi)和對象肯定會(huì )很好。

原因 2 – 微控制器的編譯器和工具鏈支持

在過(guò)去的幾年里，微控制器領(lǐng)域的編譯器和工具鏈對C 的支持一直是工具提供商的重點(diǎn)。檢查一些商業(yè)和開(kāi)源編譯器，你會(huì )很快發(fā)現編譯器完全支持最新的 C 標準。檢查這些編譯器是否符合最新的C標準，你會(huì )很幸運地找到一個(gè)甚至支持一些最新特性的編譯器。

除了編譯器支持之外，微控制器制造商開(kāi)始在他們自己的工具中包含掛鉤，以便嵌入式開(kāi)發(fā)人員能夠輕松開(kāi)發(fā)C 應用程序。

原因 3 – 活躍的標準委員會(huì )

C 標準的更新頻率遠高于C標準，這些更新不一定只是改進(jìn) C ，而是更新功能并添加新功能以跟上行業(yè)正在發(fā)生的變化。盡管C存在所有問(wèn)題、歧義和已知問(wèn)題，但更改、更新和澄清的速度非常緩慢。

原因 4 – 性能和代碼大小

在嵌入式系統中應該使用C還是C 之間的舊爭論中最大的癥結在于性能和代碼大小。開(kāi)發(fā)人員總是抱怨C 代碼比C代碼更大，性能更差。在當今的開(kāi)發(fā)環(huán)境中，現代編譯器及其優(yōu)化器非常好。而且，開(kāi)發(fā)人員可能需要進(jìn)行一些試驗或將他們的C 語(yǔ)言使用限制為可以保證性能的子集，但老實(shí)說(shuō)，無(wú)論如何我們都必須對C做同樣的事情!

結論

C 為嵌入式開(kāi)發(fā)人員提供了開(kāi)始使用面向對象方法的機會(huì )，同時(shí)，如有必要，可以繼續使用遺留的C代碼。開(kāi)始使用C 的原因有很多，繼續使用C的理由也很多，但是在接下來(lái)的幾年中，隨著(zhù)越來(lái)越多的示例代碼開(kāi)始出現在C 中，請不要感到驚訝。