【51CTO外電頭條】編程語(yǔ)言往往是各領(lǐng)風(fēng)騷三五年。最初，炙手可熱的新語(yǔ)言是Java；后來?yè)Q成了Python，隨后Ruby搶走了風(fēng)頭,之后又換成了JavaScript。而最近備受寵愛的語(yǔ)言可能大家最想不到的。信不信由你，2011年很可能是C++大行其道的年頭。

上周，最新版的ISO C++標(biāo)準(zhǔn)被全體一致批準(zhǔn)，這是C++語(yǔ)言13年來第一個(gè)重大修訂版。新標(biāo)準(zhǔn)現(xiàn)在的官方名稱是C++11，它引入的一些功能特性旨在更容易地針對(duì)現(xiàn)代并行處理架構(gòu)開發(fā)軟件，包括面向并行計(jì)算的Lambda表達(dá)式和新的數(shù)據(jù)類型。

倒不是說C++真的消亡了。與年代更久的同類語(yǔ)言C相比，C++對(duì)于系統(tǒng)編程和需要性能密集型原生代碼的應(yīng)用程序（如3D游戲引擎）來說仍是最流行的語(yǔ)言之一。

然而在其專門的小眾領(lǐng)域之外，傳統(tǒng)的系統(tǒng)編程在近些年已漸漸失寵?，F(xiàn)在的程序員日益遠(yuǎn)離原生代碼編譯，改而青睞Java和.NET等受控代碼環(huán)境。這種環(huán)境讓他們可以不用操心內(nèi)存管理和輸入驗(yàn)證方面這樣單調(diào)乏味的工作。另一些程序員為了獲得Python、Ruby和JavaScript等動(dòng)態(tài)語(yǔ)言在語(yǔ)法上的便利，愿意犧牲一些性能。

但是C++ 11出現(xiàn)在頗有意思的時(shí)間點(diǎn)。越來越多的人覺得，編程語(yǔ)言這個(gè)鐘擺偏離原生代碼也許太遠(yuǎn)了?，F(xiàn)在該是鐘擺往另一個(gè)方向擺回來的時(shí)候了。因而，C++發(fā)現(xiàn)自己多了幾個(gè)原本最不可能的盟友。

原生代碼最不可能的擁躉包括谷歌

谷歌恐怕是你最不會(huì)想到對(duì)原生代碼有興趣的一家公司。多年來，谷歌一直鼓吹桌面軟件概念已過時(shí)了這一理念。在谷歌憧憬的理想環(huán)境下，應(yīng)用程序完全在瀏覽器里面運(yùn)行；為此，它開發(fā)出了Chrome OS來證明這一點(diǎn)。

不過連谷歌都認(rèn)識(shí)到，有時(shí)候經(jīng)過解釋的JavaScript還不夠。我在以前的文章中介紹過谷歌原生客戶端（NaCl），這種沙箱環(huán)境讓Chrome瀏覽器可以下載和執(zhí)行原生二進(jìn)制代碼，以便處理性能密集型操作。這絕非谷歌在閑暇之余的試驗(yàn)活動(dòng)；上周，谷歌在Chrome的最新測(cè)試版中發(fā)布了新版本的NaCl；這項(xiàng)技術(shù)頭一次在默認(rèn)情況下被啟用。還有傳聞稱，谷歌悄然添加到最新版Chrome OS中的Netflix媒體流支持功能也依賴NaCl應(yīng)用編程接口（API）。

NaCl也不是表明谷歌對(duì)原生代碼的唯一認(rèn)可。這家搜索巨頭的Go編程語(yǔ)言之前就被廣泛稱為是“類似Java”，但這只說對(duì)了一部分。從語(yǔ)法上來講，Go某些方面的確類似Java，但Go代碼并不在虛擬機(jī)里面運(yùn)行，而是直接編譯成了原生代碼。此外，谷歌甚至確保Go二進(jìn)制代碼不但可以在桌面上運(yùn)行，還可以在谷歌應(yīng)用程序引擎（Google App Engine）云計(jì)算環(huán)境里面運(yùn)行。

很奇怪的是，這些舉措使得谷歌與位于雷德蒙的競(jìng)爭(zhēng)對(duì)手關(guān)系融洽和睦。作為世界上最大的桌面軟件開發(fā)商，微軟對(duì)待C++的態(tài)度一直比許多公司更友好?？墒墙┠陙恚鶦/C++開發(fā)人員覺得自己受到了一點(diǎn)冷落，因?yàn)槲④洶汛蟛糠志ν度氲搅薈#，這是面向.NET平臺(tái)的受控代碼C衍生語(yǔ)言。

但這種情形似乎在發(fā)生變化。Visual Studio 2010已經(jīng)支持C++11的大部分功能特性。今年7月，微軟在其Channel 9開發(fā)人員網(wǎng)站上發(fā)布了一個(gè)新的視頻系列，名為“Going Native”（使用原生代碼），專門介紹原生代碼方面的發(fā)展，特別強(qiáng)調(diào)C++。與此同時(shí)，目光敏銳的觀察人士注意到了微軟在9月召開的Build大會(huì)前夕居然沒有.Net方面的宣傳。Build大會(huì)之前名叫專業(yè)開發(fā)者大會(huì)（PDC）。

原生代碼永不沒落

早在Java時(shí)代之前就懂得編程的那些人自然完全明白為何人們重新對(duì)原生代碼產(chǎn)生了興趣。傳統(tǒng)的軟件開發(fā)方法有著悠久的傳奇歷史；有時(shí)候，經(jīng)過充分優(yōu)化的原生二進(jìn)制代碼仍是有可能從處理器獲取最高性能的最佳方法。

話雖如此，原生代碼也有其缺點(diǎn)。首當(dāng)其沖的是我之前提到的安全問題。由于與C#和Java等受控語(yǔ)言相比，C和C++等語(yǔ)言讓開發(fā)人員可以更接近底層硬件，所以要認(rèn)真考慮的問題就多得多；缺乏經(jīng)驗(yàn)的編程員可能會(huì)造成嚴(yán)重破壞。

移植性是另一個(gè)問題。對(duì)于處在Wintel環(huán)境下的Windows開發(fā)人員來說，編寫可以在多種處理器架構(gòu)上編譯的代碼從來不是個(gè)大問題，甚至在過去也是如此。然而換成了Unix環(huán)境，情況就不一樣了。

現(xiàn)在，谷歌的NaCl環(huán)境重新帶來了同樣一些問題。Web開發(fā)人員習(xí)慣于自己開發(fā)的應(yīng)用程序在任何基本上符合標(biāo)準(zhǔn)的瀏覽器中運(yùn)行，但是NaCl模塊與特定的處理器架構(gòu)死死地綁在一起。想讓同一個(gè)模塊在x86、x64和ARM等處理器上都可以運(yùn)行，你就得編譯這三個(gè)不同的版本，然后把這三個(gè)版本都放到Web服務(wù)器上。對(duì)于長(zhǎng)期習(xí)慣使用PHP和Perl的開發(fā)人員來說，這就需要一番適應(yīng)。

但要牢記的最重要的問題是，為手頭的任務(wù)選擇合適的工具。誰(shuí)也不想回到以前的糟糕年代：面對(duì)使用由C編寫的CGI腳本的Web，為文本數(shù)據(jù)而糾結(jié)。另一方面，不管手頭的任務(wù)是什么，把每一個(gè)應(yīng)用程序硬塞進(jìn)同樣的解釋語(yǔ)言或受控代碼環(huán)境同樣不是正確的方法。

現(xiàn)在的計(jì)算機(jī)異常尖端先進(jìn)、用途異常廣泛、性能異常強(qiáng)大。要充分利用它們的功能，開發(fā)人員就應(yīng)該使用盡可能廣泛的工具。原生代碼的卷土重來往正確方向邁出了可喜的一步。

原文標(biāo)題：Hail the return of native code and the resurgence of C++