C++與其他語言的比較

1、在31年前（1979年），一名剛獲得博士學位得研究員，為了開發(fā) 一個軟件項目發(fā)明了一門新編程語言，該研究員名為Bjarne Stroustrup,該門語言則命名 為一C with classes,四年后改稱為C+。C+就是一門通用編程語言，支持多種編程范式, 包括過程式、而向?qū)ο螅╫bje ct - oriented programming/ OP）、泛型（generic programming, GP）,后來為泛型而設(shè)計得模版，被發(fā)現(xiàn)及證明就是圖靈完備得，因此使C+ 亦可支持模版元編程范式（template metaprogramming, TMP）。C+繼承了 C得特色/ 既為髙級語言，又

2、含低級語言功能，可同時作為系統(tǒng)與應用編程語言。C+廣泛應用在不同領(lǐng)域，使用者以數(shù)百萬計。根據(jù)近十年得調(diào)查，C+得流行程度約穩(wěn)定排行第 3位（于C/Java之后） C+經(jīng)歷長期得實踐與演化，才成為今日得樣貌。1998年,C+標準委員 會排除萬難，使C+成為ISO標準（俗稱C+98）,當中含非常強大得標準模版庫（standard template library, STL）。之后委員會在2005年提交了有關(guān)標準庫得第一個技術(shù)報告（簡稱 TR1）,并為下一個標準C+0x而努力?？上+0x并不能在200x年完成，各界希望新標準能于 2011年內(nèi)出臺。流行得0卄編譯器中，微軟Visual C+ 201

3、0已實現(xiàn)部分C+0x語法并加入TR1擴充庫，而gcc 對C+0x語法與庫得支持比VC2010更多。應否選擇C+哪些程序適宜使用C+?C+并非萬能丹，我按經(jīng)驗舉出一些0卄得適用時機。C+適合構(gòu)造程序中需求較穩(wěn)定得部分，需求變化較大得部分可使用腳本語言； 程序須盡量發(fā)揮披件得最離性能，且性能瓶頸在于CPU與內(nèi)存； 程序須頻繁地與操作系統(tǒng)或破件溝通；程序必須使用C+框架/庫，如大部分游戲引擎（如Unreal/Source）及中間件（如Havok/FMOD）, 雖然有些C+庫提供其她語言得綁定，但通常原生得API性能最好、最新； 項目中菜個目標平臺只提供C+編譯器得支持。按應用領(lǐng)域來說,C+適用于開發(fā)

4、服務器軟件、桌面應用、游戲.實時系統(tǒng)、高性能計算、嵌入 式系統(tǒng)等。使用C+還就是C?C+與C得設(shè)計哲學并不一樣，兩者取舍不同，所以不同得程序員與軟件項目會有不同選擇，難以 一槪而論。與C+相比,C具備編譯速度快、容易學習.顯式描述程序細節(jié)、較少更新標準（后 兩者也可同時視為缺點）等優(yōu)點。在語言層面上,C+包含絕大部分C語言得功能（例外之一,C+ 沒有C99得變長數(shù)組VLA）,且提供00P與GP得特性。但其實用C也可實現(xiàn)00P思想，亦可利用 宏去實現(xiàn)某程度得GP,只不過C+得語法能較簡潔、自動地實 OOP/GPo C+得RAII （resource acqui sit io n i s init

5、ial izat ion,資源獲取就就是初始化）特性比較獨特,C/C#/Java沒有相應 功能?；仡櫄v史，Stroustrup開發(fā)得早期C+編譯器Cpre/Cfront就是把C+源代碼 翻譯為C,再用C編譯器編譯得。由此可知,C+編寫得程序，都能 用等效得C程序代替，但C+在語言層面上提供了 OOP/GP語法、更嚴格得類型檢查系統(tǒng).大量 額外得語言特性（如異常、RTTI等），并且C+標準庫也較豐富。有時候C+得語法可使程序更 簡潔，如運算符重載、隱式轉(zhuǎn)換。但另一方面，C語言得API通常比C+簡潔，能較容易供其她語 言程序調(diào)用。因此，一些C+庫會提供C得API封裝，同時也可供C程序調(diào)用。相反，有

6、時候也 會把C得API封裝成C+形式，以支持RAI I與其她C+庫整合等。為何C+性能可優(yōu)于其她語言？ 相對運行于虛擬機語言（如C#/Java）, C/C+直接以靜態(tài)形式把源程序編譯為目標平臺得機器 碼。一般而言，C/C+程序在編譯及鏈接吋可進行得優(yōu)化最豐富，啟動時得速度最快，運行時得額 外內(nèi)存開銷最少。而C/C卄相對動態(tài)語肓（如Python/Lua）也城少了運行時得動態(tài)類型檢測。此 外,C/C+得運行行為就是確定得，且不會有額外行為（例如C#/Java必然會初始化變量），也不會 有如垃圾收集（GC）而造成得不確定性延遲，而且C/C+得數(shù)據(jù)結(jié)構(gòu)在內(nèi)存中得布局也就是確定 得。有時C+得一些功能會

7、使程序性能優(yōu)于C,當中以內(nèi)聯(lián)與模版最為突出，這兩項功能使C+ 標準庫得sortO通常比C標準庫得qsortO快多倍（C可用宏或人手編碼去解決此問題）。另一 方面，C/C+能直接映射機器碼，之間沒有另一層中間語言，因此可以做底層優(yōu)化，例如使用內(nèi)部 （intrinsic）函數(shù)與嵌入?yún)R編語言。然而，許多C+得性能優(yōu)點并非免費午餐，代價包括較長得 編譯鏈接時間與較易出錯，因而增加開發(fā)時間與成本，這點稍后補充。我進行了一個簡單全局渲染性能測試（512x512像素，毎像素10000個釆樣），C+ 1小時36分、 Java 3 小時 18 分、Python 約 18 天、Ruby 約 351 天。C+常見問

8、題C+源代碼跨平臺嗎？C+有不錯得跨平臺能力，但由于直接映射破件，因性能優(yōu)化得關(guān)系，跨平臺能力不及Java及多 數(shù)腳本語言。然而，實踐跨平臺得C+軟件還就是可行得,但須注意以下問題：C+標準沒有規(guī)定原始數(shù)據(jù)類型（如int）得大小，需要特定大小得類型時，可自訂類型（如i nt32_t）,同時對任何類型使用s i zeof （）而不假設(shè)其大??；字節(jié)序（byte order）按CPU有所不同，特別要注意二進制輸入輸出、re interpret_cast 法；原始數(shù)據(jù)與結(jié)構(gòu)類型得地址對齊有差異；編譯器提供得一些編譯器或平臺專用擴充指令；避免作應用二進制接口 （appl icat ion binary

9、interface, ABI）得假設(shè)，例如調(diào)用函數(shù)時參數(shù)得 取值順序在C/C+中沒定義，在C+中也不可隨便假設(shè)RTTI/虛表等實現(xiàn)方式?？偫ǘ?，跨平臺C+軟件可在頭文件中用宏檢測編譯器與平臺，再用宏、typedef、自定平臺相關(guān)實現(xiàn)等方法去實踐跨平臺，C+標準不 會提供這類幫助。C+程序容易崩潰？與許多語言相比,C/C+提供不安全得功能以最優(yōu)化性能，有可能造成崩潰。但要注意，很多運行 時錯誤，如向空指針/引用解引用.數(shù)組越界、堆棧溢出等，其她語言也會報錯或拋出異常，這些 都就是程序問題，而不就是語言本身得問題。有些意見認為，出現(xiàn)這類運行時錯誤，應該盡童寫 入日志并立即崩潰，不該讓程序繼續(xù)運行

10、，以免造成更大得影響（例如程序繼續(xù)把內(nèi)存中錯誤得 數(shù)據(jù)覆寫文件）。若要容錯，可按業(yè)務把程序分割為多進程，像Chrome或使用fork（）得形式。 然而，C+有許多機制可以減少錯誤，例如以string代替C字符串；以vector或array仃R1）代 替原始數(shù)組（有些實現(xiàn)可在調(diào)試模式檢測越界）；使用智能指針也能減少一些原始指針得問題。 另外，我最常遇到得Bug,就就是沒有初始化成員變量，有時會導致崩潰，而且調(diào)試版與發(fā)行版得 行為可能不同。C+要手動做內(nèi)存管理？C+同時提供在堆棧上得自動局部變量，以及從自由存儲（free store）分配得對象。對于后者， 程序員需手動釋放，或使用不同得容器與智能

11、指針。C+程序員經(jīng)常進一步優(yōu)化內(nèi)存，自定義內(nèi) 存分配霓略以提升效能，例如使用對象池、自定爻得單向/雙向堆棧區(qū)等。雖然C+0x還沒加入 GC功能，但也可以自行編寫或使用現(xiàn)成庫。此外,C/C+也可以直接使用操作系統(tǒng)提供得內(nèi)存相 關(guān)功能，例如內(nèi)存映射文件、共享內(nèi)存等。使用C+常要重造輪子？我曾參與得O+項目，都會重造不少標準庫已提供得功能，此請況在其她語言中較少出現(xiàn)。我試 圖分析個中原因。首先工卄標準庠相對很多語言來說就是貧乏得，各開發(fā)者便會重復地制造自 訂庫。從另一個角度瞧工卄標準庫就是用C+編寫得（很多其她語言不用自身而就是用C/C卄去 編寫庫），在能力與性能上，自訂庫與標準庫并無本質(zhì)差別；另外

12、，標準庫為通用而設(shè)，對不同平臺 及多種使用需求作取舍，性能上有所影響，例如EA公司就曾發(fā)表自制得EASTL規(guī)格，描述游戲開 發(fā)方面對STL得性能及功能需求得特點；此外，多個C+庫一起使用，經(jīng)常會因規(guī)范不同而引起 沖突，又或功能瑩疊，所以項目可能須自行開發(fā)，或引入其她庫得概念或?qū)崿F(xiàn)（如 Boost/TR1/Loki）,改寫以符合項目規(guī)范。C+編譯速度很慢？錯，就是非常慢。我認為C+可能就是實用程序語言中編譯速度最慢得。此問題涉及C+沿用C 得編譯鏈接方式，又加入了復雜得類/泛型聲明與內(nèi)聯(lián)機制，使編譯吋間倍增。在C+對編譯方 法改革之前(如modu I e提案)，可使用以下技巧改善：第一，使用pi

13、mpl手法，因性能損耗應用于調(diào)用次數(shù)不多得類；第二,僅包含必要頭文件, 并盡董使用及提供前置聲明版本得頭文件(如iosfwd);第三釆用基于接口得設(shè)計，但須注意虛 函數(shù)調(diào)用成本；第四，釆用unity build,即把多個cpp文件結(jié)合在一個編譯單元進行編譯；第五, 釆用分布式生成系統(tǒng)如IncrediBui IdoC+缺乏什么功能？雖然C+已經(jīng)非常復雜，但仍缺少很多常見功能。C+0x作出了不少改基，例如語言方面加入 Lambda函數(shù).閉包、類型推導聲明等，而庫方面則加入正則表達式、釆用哈希表得 unordered_set/unordered_map 引用計數(shù)智能指針 shared_ptr/wea

14、k_ptr 等。但最值得留意 得就是C卄Ox引入多線程得語法與庠功能，這就是C+演進彳g大步。賽而，模組、GC、反射機 制等功能雖有提案，卻未加進C+0x。C+使用建議為應用挑選特性集我同意Stroustrup關(guān)于使用C+0種技術(shù)得回應：“您可以做，不意味著您必須這么做。(Just because you can do it, doesnt mean that you have to ) C卄充滿豐富得特性，但 同時帶來不同問題，例如過分復雜、編譯及運行性能得損耗。一般可考慮就是否使用多重繼 承、異常、RTTI,并調(diào)節(jié)使用模版及模版元編程得程度。使用過分復雜得設(shè)計與功能，可能會令 部分團隊成員

15、更難理解與維護。為團隊建立編程規(guī)范C+得編碼自由慶很鬲，容易編寫風格迥異得代碼,C+本身也沒有定狡一些標準規(guī)范。而且,C+ 得源文件物理構(gòu)成，較許多語盲復雜。因此，除了決定特性集，毎個團隊應建立一套編程規(guī)范，包 括源文件格式(可使用文件模版八花括號風格。盡童使用C+風格而非C風格由于C+有對C兼容得包袱，一些功能可以使用C風格實現(xiàn)，但最好使用C+提供得新功能。最 基本得就是盡童以具名常量、內(nèi)聯(lián)函數(shù)與泛型取代宏，只把宏用在條件式編譯及特殊情況。舊 式得C要求局部變量聲明在作用域開端,C+則無此限制，應把變董聲明盡董置于鄰近其使用得 地方,for ()得循環(huán)變量聲明可置于for得括號內(nèi)。C+中能加

16、強類型安全得功能應盡瑩使用， 例如避免“萬能”指針void *,而使用個別或泛型類型；用bool而非int表示布爾值;選用4 種C+ cast關(guān)鍵字代替簡單得強制轉(zhuǎn)換。結(jié)合其她語言如前文所述,C+并非適合所有應用情境，有時可以混合其她語言使用，包括用C+擴展其她語言, 或在C+程序中嵌入腳本語言引擎。對于后者，除了使用各種腳本語言得專門API,還可使用 Boost或SWIG作整合。C+學習建議C+缺點之一，就是相對許多語言復雜，而且難學難精。許多人說學習C語言只需一本K&RC程序設(shè)計語言即可，但C+書藉卻就是多不勝數(shù)。我就是從C進入C+,皆就是靠閱讀自學。在此分享一點學 習心得。個人認為，學習C+可分為4個層次：第一層次，C+基礎(chǔ)：挑選一本入門書籍，如C+ Pr imer C卄大學教程、或Stroustrup 撰寫得經(jīng)典C+程序設(shè)計語言或她一年半前得新作C+程序設(shè)計原理與實踐，而一般 C+課程也止于此，另外C+標準程序庫及The C+ Standard Library Extensions可 供參考；第二層次，正確離效地使用C+:此層次開始必須自修，閱讀過(More) Effective C卄.(More)Except ionaI C+、Effect i ve STL及C+編程規(guī)范等，才適宜踏入專業(yè)C+ 開發(fā)之路；第三層次，深入了解