C\C++編譯器的將來.咱們還須要C++麼?

  在將來咱們還須要純C++開發模式麼?

  隨着C++11的誕生,C++已經愈來愈臃腫,從03的時候就以爲C++實在是太複雜了。以一個合格C++程序員的標準來簡單的來講3-5年略有小成,5-8年才能夠說本身是個合格的C++程序員,10年以上纔敢處處和別人說本身精通C++,不至於被某人用個很bt的問題問倒。C++程序員的培養成本過高了。

  隨着技術的發展與進步，還有產品的複雜性，致使了開發開始走了多樣性，誰都想更快的開發速度，更好的質量。因而混合開發已是很多公司採用的方案了。使用python,ruby,java,php才高層開發，性能瓶頸採用c來開發.這個更適合當今的開發方式。須要用到C++的地方愈來愈少。

  C++程序員一直引以自豪的是C++能夠擁有OO的控制能力，又同時擁有C的性能。C++誕生於80年代，當時的硬件性能的確不行，進入21世紀後隨着硬件技術的不斷髮展，如今Java爲表明的虛擬機或者動態語言開發更加成爲主流平臺。企業級開發中C++的份額愈來愈少，與C+彙編相比底層開發，C++因爲資源佔用和過於複雜的結構致使了在系統底層開發也不佔據優點。(好比操做系統,驅動,單片機,嵌入式等領域.C++其實不多用,即便用了也是簡單的OO包裝,幾乎不會使用stl等高級特性)甚至連linux都徹底不用C++開發內核.

C++的幾大問題.

1.運行速度和佔用資源:目前來講C++的運行速度和資源佔用確定比C是高許多.並且特性越多C++編譯程序的規模也愈來愈大。編譯速度也是一個很是大的問題，一編譯好幾十分鐘的工程也不是罕見的事情

2.移植性和擴展性:許多小型嵌入式平臺根本沒有C++編譯器或者沒有完整的支持C++特性的編譯器.對於通常公司和我的來講維護C編譯器是能夠作到的，但是維護一個C++編譯器那是根本沒法想象的。並且C++雖然有標準但是二進制兼容性和各類參數傳遞方式卻沒有一個統一的標準，與此相比C就徹底沒有這個問題。

3.人員,開發,調試,管理成本:許多時候不須要極限性能的產品(若是須要也不會用C++而是上fortran之類的語言)C++的程序員價格很高,並且因爲C++實在過於複雜致使了老人走了新人拿着代碼沒法維護的事情頻頻發生.並且如今python,ruby,lua等動態語言的興起C++緩慢的開發速度與之相比至關沒有性價比,更多的人開始流行C+Python(Lua,ruby)的開發模式.須要性能的地方用C開發,加上Python,Ruby先進的包管理,更加完善的面向對象支持和各類語法糖C++愈來愈沒什麼必要了...並且開始i有工程直接把Python,Ruby輸出爲C語言或者乾脆成爲一個編譯器也不是不可能的.並且各類比Java更加優秀的Jit誕生後，C模塊調用成本也至關低，甚至能夠徹底和C++相媲美。在調試和測試的成本低廉的狀況下，C++的成本的確是讓人值得思考是否值得使用。

4.真正須要C++工程:固然許多人以爲遊戲引擎呀，各類底層的引擎呀仍是須要C++的，以第三條爲例，遊戲引擎之後愈來愈多的走向快速開發和制定化，模塊拆分天然也是必然的。C構造底層(包括python轉換成c也算進去)天然能夠應用的上。並且遊戲如今愈來愈偏向於腳本化，畢竟引擎不是每一個人都須要去修改，大部分人只是學習如何使用就能夠了，Lua\Python+一個合適的Jit性能就徹底能夠保證了。

基於以上這四條，之後咱們還有必要使用C++麼？C++框架至關少，找來找去也就是那幾家大型商業公司，微軟（不具有跨平臺性），Intel（不支持ARM，MIPS等其餘），GCC（通常人難以擴展，即便5.0出來後也未必是通常公司有擴展能力的），LLVM（同GCC同樣，過於龐大，並且優化度和將來如何發展仍是個問題）。而C編譯器幾乎通常公司都有能力維護，甚至一我的均可以維護。(lcc,pelles c,tcc等許多許多c編譯器)

有人說有人有維護編譯器的必要麼？遠的不說就說近的吧，愈來愈的移動處理器出如今市面上，各家IP雖然都用的是Soc的可是各類優化和特殊指令仍是有的。例如君正的JZ系列，ARM的各類處理器也是有本身的特殊指令的。那對於芯片廠商和平臺，中間件等第三方廠商來講。可以直接在CPU中添加硬件加速和軟件直接利用硬件指令固然是效果最好的。那麼將來還有必需要使用C++這種成本很高的編程語言麼？固然也許不能徹底否認，可是目前C++的地位的確是愈來愈降低。再加上各類成本，C++的前途很值得擔心。

好奇號250w行C代碼，100w行手寫(以此來看C不是不能開發大型工程,大型工程重要的是設計而不是語言,設計模式也不是OO的專利)，其他的都是靠自動化工具生成，即便換上特殊的CPU，本身重寫codegen函數也是一兩我的徹底能夠作到的。但是反觀C++，那種規模的編譯器我想絕對不是一兩我的能夠維護的了的。ruby,python的編譯器也都是基於c寫的。luajit雖然不成熟可是帶來的優化性能讓咱們看到了，輕量級語言其實仍是具備可觀的性價比的。那剩下的問題就僅僅在於call的性能了。小函數有必要，大的函數其實inline看不出什麼性能的提高。並且也徹底能夠依靠動態語言jit的優化來解決這個問題。高級動態語言JIT速度通常不行的緣由也在於函數太大和全局優化在「即時」狀況下仍是不足以作到很完善的優化。固然了小一點的函數仍是能夠作的挺好的，並且隨着編譯器技術的發展，這種問題確定也會獲得有效的解決，實在不行還能直接生成C代碼，再用C編譯器進行交叉編譯。

爲此我從兩年前就開始作了一種嘗試，本身開發底層asm,c的交叉編譯器(前面說過了我的維護asm,c的交叉編譯器仍是能夠作到的C++就不是一我的能夠扛得住的了).目前作的就是使用c語言重構fasm和Ansi c交叉編譯器，而後是基於Ansi c的跨平臺界面庫和一種輕量級動態語言的JIT。以此爲中間件來開發之後的程序。

固然其中還會遇到許多難題，可是都是能夠解決的。技術在發展，程序設計也在發展，一些老的沒必要要的傳統也能夠放棄了。至少在我的看來C++徹底能夠被前面介紹的開發模式替換掉。更輕量級，更簡單的交叉編譯器。

固然了go語言也是一個不錯的選擇，雖然他仍是有許多問題。之後等技術成熟和有足夠的資源的時候會嘗試開發一個跨平臺的Rad工具(我的很喜歡delphi但是它不跨平臺。並且許多特性也知足不了輕量級需求，可是它很優秀)