編譯器的將來——咱們還須要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但是它不跨平臺。並且許多特性也知足不了輕量級需求，可是它很優秀)

參考：http://my.oschina.net/sw23120/blog/119584

-----------------------------------------------------------------------------------

好吧 開始評論，我以爲C++不難學，難學的是架構的思想,Framework以及平臺特性。

第一C能夠作到的 C++依然能夠作到，如今開發的問題主要是架構的老化，不要認爲Lua，Java之類的東東效率高，Lua，C#這種東西比較新，框架比較新，因此還有很強的效率，Java架構都開始老化了，甲骨文沒有的支持並不給力，頻頻爆出漏洞。而C++基本上流行的框架都到了要革新的時候了，MFC近20年，ATL也不少年了 在小型開發上來說這是一種危害，效率低下，一個框架也都是向着複雜發展。只能是功能愈來愈多愈來愈複雜。這就是C++的主流困惑。
不過話有講回來，當你代碼量達到必定程度，而且又要高效，那麼仍是用C++，如今的LLVM/Clang所有用C++代碼實現，GCC已經能夠用g++（C++方式）編譯，大型的項目要經過模塊化簡化開發難度，包括Java的編譯器都是用C++實現，高超的C++項目是類和模版並用的。而且大量的虛擬機代碼是危害效率的。

-----------------------------------------------------------------------------------

C++不難學是您認爲的，會的人固然以爲不難，我也以爲C++不難可是我不以爲C++是必須須要用到的，您認爲您須要C++的時候其實您須要的也許是Python或者Delphi之類的。一個合格的C++程序員的確須要3-5年才能修煉成功這個已是廣泛觀念了，並且性價比很低。

C能夠用在單片機一些內存極小的嵌入式平臺上，VxWorks等平臺，這些都是C++作不到的。因此不要再說C能夠作到的C++也能夠作到。就這點C++就作不到。固然你能夠徹底寫C Style的C++，但是那樣的C++還有什麼意義麼？

C++是一個貪大求全的產物，當時OO剛興起，什麼都像往上上，縱觀歷史發展這種問題不是沒有，古代士兵都上重甲，重裝。後來隨着戰術的發展愈來愈發現速度遠比防護要重要的多。C++什麼都要上，C能作的他要能作，動態語言能作的他也要能作。如今徹底就是爲了全面而全面的擴展本身的性能了，C++11一看幾乎涵蓋了操做系統要作的東西了，就差垃圾回收+智能指針或者模板就能夠稱本身爲動態語言了。一個如此複雜的語言學習成本又過高，STL和Boost其實也日漸老化，固然Boost我幾乎沒仔細學過，可是光看着這種重量級的架構我就以爲，這東西絕對不是我要的。
若是開發你用了100%的精力，那出錯和調試您須要多大的精力？

Lua能夠作到接近於C++的速度，設計結構老化是須要歷史來證實的，用的人多了天然缺點慢慢顯現出來，C++也是這樣，早期你們認爲OO能夠抽象萬物，可是他卻忘記明日是不可預料的，你猜不出明天有什麼需求，如何能預留出接口呢？效率低下能夠改進。可是C++不是誰都能維護的太大的體積和各類成本後C++絕對不是很好的選擇。
C++的確是模板+類混用的，但是因爲這樣的結果帶來了程序的複雜性，linux代碼很簡單，隨便一個c程序員均可以抄一段來用。但是我看過的C++工程那種複雜度實在不是通常人能看得懂，說句很差聽的給你代碼你都未必知道寫的是什麼，許多研究生處處兜售代碼，但是沒什麼人買的緣由也就是如此，看不懂實在是看不懂。
開發動態語言，須要性能和底層上C或者彙編來寫。一切都調試ok了，實在不行還能夠把動態語言直接輸出成c語言。整體開發週期確定小於C++，性能也絕對和C++至關甚至更強。虛擬機技術也在進步，雖然如今沒法徹底達到，可是不是作不到好比dotNET就作的很是好.
另外我說的小型處理器廠商的方案如何處理？維護gcc這樣的工程須要一個很是大的團隊。而一個c編譯器只須要很小的團隊，並且c語法因爲簡單，因此代碼邏輯優化等等都比C++容易得多的多。這種優點必須看到，並且要知道以中國爲例，編譯器領域的人才其實百裏挑一。要集結5-10我的的C++團隊天然不如只須要1-2人的c團隊要性價比更高~
固然我的認爲的，大牛能夠有其餘更好的解決方法洗耳恭聽。

-----------------------------------------------------------------------------------

至於蘿蔔白菜各有所愛，好比我，傾向於研究操做系統，開發框架之類的底層，習慣認爲C++好，而你的注重點不一樣，喜歡C，Python等，語言並無什麼優劣之分，只是適合幹什麼不適合幹什麼，根據你的定位去選擇語言，在獲取一些語言特點的同時確定有所失，有得有失纔是正常，還有評價一個語言儘可能的客觀一些。這樣是有好處的。專一技術而不是專一分歧。

-----------------------------------------------------------------------------------

操做系統幾乎沒有用C++開發的，請問您怎麼用C++開發操做系統的？windows，linux，bsd，嵌入式操做系統，實時就更不用說了，幾乎所有是c+asm開發的，您這句傾向於研究操做系統根據何在呢？
我一直都是用c+asm，delphi寫代碼的。這個就是讓我感受到迷茫的地方，C++的優點究竟在哪裏，我用了兩三年的C++，最後我仍是決定退回到c+asm,C++的優點逐漸的被自身複雜和高昂的成本抵消了。
我的自己是作操做系統核心層的東西，包括安全，逆向，網絡底層等研究的。並且越是這種底層越看不見C++，至於開發框架~C++也沒法帶來快速開發的效果，反而調試和移植成本會增長。這也是讓我一直很頭疼的事情。
至少我我的找不到使用C++的必要性了。固然了蘿蔔青菜各有所愛。
隨着go等新型編譯語言的誕生，人們更多的是須要輕量級而不是C++這樣的龐然大物。並且都有替代方案，動態語言的特性更容易管理代碼。C++還真的須要麼？只是本身的我的想法，提出一種拋開C++的開發方案。固然只是我的的想法。多謝您的指點。

HaikuOS 引導都是C++，我對你的見解表示遺憾

-----------------------------------------------------------------------------------

樓主的說法是如今C++沒什麼用武之地？但爲何我以爲如今大部分的桌面程序仍是C++開發的？至少如今的java,python,ruby仍是多用在服務端的開發吧，這些語言開發的桌面程序除了Eclipse之類的開發工具和比特彗星，openoffice，其餘的恐怕並很少吧，就算你能列舉出來幾十個，能和C++的量比嗎。QT,wxWidget之類的gui庫自己就是用C++開發的，這不足以證實C++在這方面的優點嗎。遊戲開發就更不用說了，無論是開源仍是閉源引擎，90%以上都是C++開發。約翰 卡馬克剛開始也是用C來寫的ID TECH引擎，到DOOM3的時候不也轉C++了？別用本身的主管判斷去否認產品，STL和BOOST的開發人員我以爲至少比你高明吧，他們難道閒着沒事作這些複雜的工做打發時間？該死的東西總歸會死，好比什麼visual foxpro之類的，你說C++沒用？困怕還早了點，並且這種話題不免引口水。就算是Linus都被人噴的飛去，況且你呢。

-----------------------------------------------------------------------------------

你第四條寫的什麼python/lua + 一個合適的jit性能就足以保證了……這種玩笑仍是別開了，我不知道那些語言寫出個cry3畫質的程序幀數會是什麼樣子。java開發的最成功的客戶端遊戲MC的執行效率足以證實。遊戲引擎只有在腳本部分纔會用到那些語言，lua就是那麼被wow帶火的。但wow的主題部分會用lua去寫嗎？C++還不須要虛擬機，依賴庫，你又想說delphi也不要……固然delphi也不錯，原來的第三方控件也不少，但如今用的人也很少吧，被寶藍賣了後都不知道怎麼樣了，並且彷佛仍是走向了.net路線。果真VCL和MFC都老了。

-----------------------------------------------------------------------------------

我可沒以爲STL，Boost比我的寫高明多少（你能夠說重複造輪子，我來告訴你，內存佔用太大，通用型根本不頂用給小菜用用能夠，實際工做中用到的算法都要分支，動態規劃從新設計的，因此STL，Boost根本沒用。這就是CPU和FPGA的區別，真的高精度算法只能本身寫，你沒遇到只能說您作的工做實在是。。），DOOM3的代碼是沒辦法，只能這麼改（因爲id被收購，並且大部分的引擎使用者都是C++er卡馬克不得不妥協，難道你讓那些C++程序員放棄C++都用c？）-仔細看過代碼你就知道了。那叫C++？別由於看到幾個class就認爲他用C++其實很C style，另外C的佔有率遠比C++高得多。再來講說您所謂的C++優點吧，C++優點其實只有一條執行速度夠快（另一個很小的優點原生代碼好加密）。要說OO和開發效率什麼的真的不如動態語言來的快節奏。動態語言因爲更好的動態特性能夠提供更增強大的OO特性，這點C++是根本趕不上的（C++的各類特性實在是很差支持，因爲是編譯型語言因此C++編譯器愈來愈臃腫，編譯速度愈來愈慢）如今很多人還在用C++的緣由實際上是由於他們已經再用C++了。這就比如許多人就是習慣用XP，忽然換成Win8以爲還不如XP呢，又換回去了。其實懶是最主要的緣由。python，ruby，java不是不能開發客戶端（大部分客戶端不須要多高的性能需求，即便須要也徹底能夠用C來寫）其實仍是說那句話，沒有人肯爲這些語言的桌面化做出努力。若是徹底拋開執行效率來講的話。您以爲哪一種語言更適合使用呢？
linus被噴的緣由是語氣和態度，另外我不以爲C++有什麼好的。不合格的C++程序員只會讓代碼更糟糕這個的確是真的（C++提供的特性太多，以致於許多小菜一上來什麼特性都往裏面用，並且stl，boost編譯，調試很複雜，估計他走了也麼人搞得懂這段代碼寫什麼）linux內核須要的是一種是我的都能看得懂一目瞭然的代碼。越簡單的代碼越容易維護。固然c也不是無懈可擊（包管理太爛了。C++的namespace就很好，但是和python，ruby比又弱了許多）放棄C++是必然的，由於有更多新的語言誕生，更適合多人協做開發，包管理，模塊化設計等等。另外stl，boost的算法通常人寫寫也要不了多久，他們沒事搞這麼複雜的東西其實就是閒着沒事作了，好比loki就是爲了證實本身能作到而搞的東西。將來多種語言維護的工程確定愈來愈多。單一須要C++的不是不少了。即便是遊戲C+lua或者Python也是能夠搞定的。邏輯部分不須要太多的性能計算。

-----------------------------------------------------------------------------------

大部分工程不須要很高的性能，好比界面庫用C+asm來開發足以保證速度了，我說還有必要使用C++麼不是說不用asm+c，即便是cry3內部也是嵌入了大量的asm來優化速度。你說的東西老是那麼單一和絕對的東西，我又說徹底使用一種語言開發麼？不用c就用java？我從一開始說的就是混合開發沒說使用單一語言開發。另外不懂delphi別說delphi，delphi被易博龍收購之後，出了Xe系列，如今XE3.5已經能夠直接開發iOS程序了（原生直接編譯出來，不須要freepascal了）並且VCL早就沒人關注了，界面庫也換成了FireMonkey，底層是DirectX+OpenGL實現的動態自繪窗口，也是爲了跨平臺設計的，固然因爲高手走了很多體積實在是太大了（用了LLVM，沒辦法，不過如今還有多少人在意多1m仍是少1m的體積呢）XE4是能夠直接開發Android和iOS程序的。.NET的話delphi早不玩了，VCL雖然說比MFC先進，可是delphi如今也不是主力玩這個了。易博龍徹底把它往跨平臺方面打造了。能夠搜索一下FireMonkey。
這是一個快速迭代開發的時代，C++過重量級了，開發速度也很慢。使用快速的混合開發不是一種很好的方式麼？固然我一開始就說這只是我我的推薦和使用的方式，你們是否是也須要就看我的的。
並且我說的層次和您用的方式不同。C編譯器通常人也能夠維護起來，C++就不見得了（一些大廠商到如今尚未徹底兼容C++03,11也只是有一部分支持）能夠制定化製造本身CPU的公司也愈來愈多，爲了得到更好的效能，如今都是Soc-CPU+GPU+VPU+FPGA加速。那問題就來了大廠商不會去幫你小廠商作支持的，並且小CPU廠商也沒辦法維護C++編譯器。那最後仍是要回到放棄FPGA的方式--沒人開發編譯器。若是使用C就能夠有效的解決這個問題。一兩我的維護c交叉編譯器不是難事。
不要誤解我，我沒有說其餘語言比C++強，而是混合開發的優點大於C++。圖形引擎須要性能這個沒的說，用ASM+C來開發，但是邏輯部分其實沒多少性能需求用Lua,python也足夠了，好比lua這樣的輕量級語言，維護個Jit不是難事一我的也足夠用了。芯片廠商專門劃出一兩我的來維護本身芯片加速指令和jit也是徹底能夠作到的。
請問這種方式不是更適合將來的開發模式麼？固然了界面庫之類的是須要徹底從新開發，可是這也是大勢所趨。並且我我的也在這方面開始本身的工做了，如今已經完成了windows，linux的一部分跨平臺界面庫（圖形自繪的不是利用已有界面庫）保證每一個平臺都獲得相同的界面結果，asm+c寫的底層速度有保證。即便將來要移植到嵌入式下也是換個交叉編譯器從新編譯的事情。

-----------------------------------------------------------------------------------

Delphi從VCL，CLX開始都是開源的，firemonkey如今也是開源的。直接就能夠看到源代碼。你能夠直接修改之類的，VC不是RAD開發工具，只適合開發一些對性能需求很大的，而不是和作一些快速迭代開發。C#主要目標是Java，其實你仔細看就能夠發現徹底就是一個類Delphi的C系列語言。
主要也是面向企業級的，Delphi從誕生就是VBKiller不是給Delphi說好話，目前易博龍的確是作的比當初Borland要好的多。
隨着Linux和OSX的崛起，Windows的市場不會再像之前這麼大了。
話說回來了都選擇C\C++還把本身捆綁在Windows上不是有點說不過去麼？之因此如今很多人還在用windows仍是那句話。windows應用軟件很成熟，Linux，OSX上開發根本都不須要什麼創新，能把windows上比較經典的東西移植過去就是巨大的成功了。
phone,pad畢竟只是娛樂性產品，最終仍是要回歸原生開發上，JIT性能不是想象的這麼好，並且更好點。用戶纔不關心你用什麼開發，開發多久，人家想要的除了是更好用，還有速度更快，更省電。這正是原生開發的優點所在。固然對於C++我沒什麼想說的。C++程序員大部分都太爛了，過度迷信於設計模式和OO抽象機制。
程序=數據結構+算法。而不是什麼抽象模型，誰也沒法保證你今天寫的結構還能知足明天的開發須要。
並且ASM+C有更好的優化和移植性。上層使用C++或者Lua或者Python來封裝便可。業務邏輯常常須要修改，選擇更具便捷性的語言纔是正路，而C++不是什麼好的設計語言。對於OO的詮釋不完善並且開發成本很高，調試成本就更高了。

-----------------------------------------------------------------------------------

很差意思我誤解您的意思了。我是想作成Pelles'c這樣的開發工具（並且本身構造一個交叉編譯器和開發工具）而不是想單純的要到OSX或者linux下從新編譯。ASM+C我以爲足矣。上層配合Lua或者Python來調用也能夠。實際優化上C++不佔優點。並且64位下大部分編譯器也都很不靠譜。VC++都沒法內嵌asm，masm64竟然連invoke和sdk包也沒有。一切都要靠本身來實現呀。打算作完一個基礎界面庫的時候開源。高速界面庫之後再說。目前基礎界面庫能夠跑在Linux-GTK，Windows上了OSX目前在考慮是採用x11仍是用Quartz。(x11其實很難用-快三十年了,所謂的經典設計說白了就是傳統設計很難用)將來計劃中其中一個很重要的環節。
其實對於開源我相對保守，我以爲在中國別玩開源-就算開源也商業開源，老外玩得起是人家收入福利都夠高，本身都還吃不飽就別裝大方了。之因此中國程序員待遇低差說白了就是用開源的太多了。

-----------------------------------------------------------------------------------

ASM+C主要是用來作底層的，文章上已經說的很清楚了，好比說許多編譯器暫時尚未聰明到能夠把一些算法採用SIMD指令進行優化，因此ASM有些底層仍是頗有意義的，好比遊戲和圖形引擎中大量的使用內嵌彙編，包括操做系統的引導部分ASM都有須要必要存在，C主要用來組織和編寫數據結構部分的代碼。ASM只是爲了彌補C的不足。固然你也能夠用C寫，但是做爲一個遊戲引擎程序員不會asm優化實在說不過去。內核程序員不會asm也說不過去。
將來的發展絕對不多是windows統一天下，若是linux和osx上的程序也和windows同樣多的話。誰還會在windows上玩？病毒這麼多（實際上是客觀緣由形成的）之後平板，桌面，工做站都須要UI部分。
不是全部人都須要去維護一個引擎，不然遊戲公司幹什麼都買引擎而不去本身開發，就是開發成本過高，買一個比較容易，並且開發週期也很短，賺錢快。看過遊戲引擎代碼就知道了裏面很多代碼都是asm優化的。OpenGL，DirectX只是提供了很是簡單的圖形操做接口，而不會幫你優化各類圖形算法。因此開發通用跨平臺的界面庫我以爲至少我須要-DirectUI這樣的。
你有錢的話，你會買apple的本本麼？若是apple也能夠dota，也能夠視頻，看片，play各類遊戲的話。有錢人誰還用windows？
最後操做系統就會發展成：
用windows的都是屌絲
用OSX的都是有錢人
用linux的都是geek

程序員就要寫出凌駕於操做系統和硬件上的軟件，爲何老是要給微軟打工呢？不要老是想着給本身省事，要想着給用戶省事，用戶須要什麼。而不是老是想着本身開發簡單，簡單的東西別人都能作。你作出來也體現不出價值，要能作別人不能作的。

另外delphi xe4寫的程序能夠在iOS,OSX,Windows上執行。聽說還要加入ARM支持，這樣的話Android和iOS原生開發均可以進行了。至於您說的win7-delphi是最先支持win8開發的。能夠下載個lite版本嘗試一下。

-----------------------------------------------------------------------------------

linux桌面如今也開始興起了，許多遊戲公司好比暴雪和valve都已經開始linux上的遊戲開發了。開放一下思路。若是windows上的軟件linux上都有。UI同樣很簡單漂亮誰願意去買個windows？ubuntu就不是給服務器準備的。並且也都帶桌面環境。另外說句很差聽的。一樣的軟件linux或者OSX支持的話價格就比windows版本價格高出好多。並且OSX的反盜版和linux下的破解技術目前還很是落後（linux下源碼調試都很痛苦，更別說在尚未什麼好的二進制調試器的狀況下玩破解了,Windows下有ollydbg,ida,windbg等等）
Delphi XE+是原生開發根本不須要其餘的DLL之類的就是體積有點大。2M左右，壓縮一下也能夠很小。你試過delphi的開發環境就知道了遠比vs要強大的多。2010後delphi開始支持泛型,RTTI等特性(基本都沒用過)
GO語言不適合開發桌面程序，首先開發桌面程序須要有界面庫，IDE，調試器等多種配合才能夠，WebKit您以爲效率夠不？用戶不關心你用什麼開發，他們要更穩定，更快，更強大。並且webkit體積太大了吧？並且性能不好。你要是開發個遊戲呢？
碼奴的思惟是怎麼給本身省事，程序員的思惟是怎麼給用戶省事。
技術難度高還能提升產品競爭力呢。不要站在代碼角度而是用戶角度去思考問題和選擇技術。

-----------------------------------------------------------------------------------

語言爭論真的是不少不少，但能夠歸根結底，是因爲人之3~5年所學，不但願別人輕易否認過期或者不行，這不就等於在否認這我的麼？其實，C++能活到如今還前三（至少也是有科學依據的，對吧），一是歷史遺留，二是確實有過人之處，正所謂，可恨之人必有可敬之處。如今C++的問題，不在於其龐大，由於你盡能夠選擇本身喜歡的部分，而不須要求全。C++的問題還在於教學上，現存的C++er幾乎都是從C學過來的吧，這樣說來，使用C++的方式仍是C的方式，C++支持多範式，從前面的討論就能夠看出來，class+template，是的！這纔是基於對象而非面向對象的方式之一。C++語法是比其餘語言多，這也正是他的優點之一，C++可讓咱們能夠玩，其餘語言能玩嗎？雖然這句話很偏激，老闆也不會喜歡！語言是配料，不是工具！配料決定了設計方式，因此，語言會決定設計！從而影響更多後續。這也就解釋了爲何不少人以爲C++的開發效率和可維護性不好--那是由於你的思惟方式不一樣啊！好吧，C++並不適合OO，這是OO的侷限和C++的侷限共同形成的，C++發展到今天，並非龐大了，而是愈來癒合理，不過C++走在一條很荊棘的路上，既要能實現合理的抽象，知足變化，也還要高效的實現效率（設計效率、編譯效率、運行效率），這，真慘！不過，生命在於折騰，不是嗎？