青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

C++ Programmer's Cookbook

{C++ 基礎} {C++ 高級} {C#界面,C++核心算法} {設計模式} {C#基礎}

C++強大的背后


轉自:http://www.cnblogs.com/miloyip/archive/2010/09/17/1828449.html

在31年前(1979年),一名剛獲得博士學位的研究員,為了開發一個軟件項目發明了一門新編程語言,該研究員名為Bjarne Stroustrup,該門語言則命名為——C with classes,四年后改稱為C++。C++是一門通用編程語言,支持多種編程范式,包括過程式、面向對象(object-oriented programming, OP)、泛型(generic programming, GP),后來為泛型而設計的模版,被發現證明是圖靈完備的,因此使C++亦可支持模版元編程范式(template metaprogramming, TMP)。C++繼承了C的特色,既為高級語言,又含低級語言功能,可同時作為系統和應用編程語言。

C++廣泛應用在不同領域,使用者以數百萬計。根據近十年的調查,C++的流行程度約穩定排行第3位(于C/Java之后)。 C++經歷長期的實踐和演化,才成為今日的樣貌。1998年,C++標準委員會排除萬難,使C++成為ISO標準(俗稱C++98),當中含非常強大的標準模版庫(standard template library, STL)。之后委員會在2005年提交了有關標準庫的第一個技術報告(簡稱TR1),并為下一個標準C++0x而努力。可惜C++0x并不能在200x年完成,各界希望新標準能于2011年內出臺。

流行的C++編譯器中,微軟Visual C++ 2010已實現部分C++0x語法并加入TR1擴充庫,而gcc對C++0x語法和庫的支持比VC2010更多。

應否選擇C++

哪些程序適宜使用C++?

C++并非萬能丹,我按經驗舉出一些C++的適用時機。

  • C++適合構造程序中需求較穩定的部分,需求變化較大的部分可使用腳本語言;
  • 程序須盡量發揮硬件的最高性能,且性能瓶頸在于CPU和內存;
  • 程序須頻繁地與操作系統或硬件溝通;
  • 程序必須使用C++框架/庫,如大部分游戲引擎(如Unreal/Source)及中間件(如Havok/FMOD),雖然有些C++庫提供其他語言的綁定,但通常原生的API性能最好、最新;
  • 項目中某個目標平臺只提供C++編譯器的支持。

按應用領域來說,C++適用于開發服務器軟件、桌面應用、游戲、實時系統、高性能計算、嵌入式系統等。

使用C++還是C?

C++和C的設計哲學并不一樣,兩者取舍不同,所以不同的程序員和軟件項目會有不同選擇,難以一概而論。與C++相比,C具備編譯速度快、容易學習、顯式描述程序細節、較少更新標準(后兩者也可同時視為缺點)等優點。在語言層面上,C++包含絕大部分C語言的功能(例外之一,C++沒有C99的變長數組VLA),且提供OOP和GP的特性。但其實用C也可實現OOP思想,亦可利用宏去實現某程度的GP,只不過C++的語法能較簡潔、自動地實現OOP/GP。C++的RAII(resource acquisition is initialization,資源獲取就是初始化)特性比較獨特,C/C#/Java沒有相應功能。回顧歷史,Stroustrup開發的早期C++編譯器Cpre/Cfront是把C++源代碼翻譯為C,再用C編譯器編譯的。由此可知,C++編寫的程序,都能用等效的C程序代替,但C++在語言層面上提供了OOP/GP語法、更嚴格的類型檢查系統、大量額外的語言特性(如異常、RTTI等),并且C++標準庫也較豐富。有時候C++的語法可使程序更簡潔,如運算符重載、隱式轉換。但另一方面,C語言的API通常比C++簡潔,能較容易供其他語言程序調用。因此,一些C++庫會提供C的API封裝,同時也可供C程序調用。相反,有時候也會把C的API封裝成C++形式,以支持RAII和其他C++庫整合等。

為何C++性能可優于其他語言?

相對運行于虛擬機語言(如C#/Java),C/C++直接以靜態形式把源程序編譯為目標平臺的機器碼。一般而言,C/C++程序在編譯及鏈接時可進行的優化最豐富,啟動時的速度最快,運行時的額外內存開銷最少。而C/C++相對動態語言(如Python/Lua)也減少了運行時的動態類型檢測。此外,C/C++的運行行為是確定的,且不會有額外行為(例如C#/Java必然會初始化變量),也不會有如垃圾收集(GC)而造成的不確定性延遲,而且C/C++的數據結構在內存中的布局也是確定的。有時C++的一些功能會使程序性能優于C,當中以內聯和模版最為突出,這兩項功能使C++標準庫的sort()通常比C標準庫的qsort()快多倍(C可用宏或人手編碼去解決此問題)。另一方面,C/C++能直接映射機器碼,之間沒有另一層中間語言,因此可以做底層優化,例如使用內部(intrinsic)函數和嵌入匯編語言。然而,許多C++的性能優點并非免費午餐,代價包括較長的編譯鏈接時間和較易出錯,因而增加開發時間和成本,這點稍后補充。

我進行了一個簡單全局渲染性能測試(512x512像素,每像素10000個采樣),C++ 1小時36分、Java 3小時18分、Python約18天、Ruby約351天。評測方式和其他語言的結果詳見博文

C++常見問題

C++源代碼跨平臺嗎?

C++有不錯的跨平臺能力,但由于直接映射硬件,因性能優化的關系,跨平臺能力不及Java及多數腳本語言。然而,實踐跨平臺的C++軟件還是可行的,但須注意以下問題:

  • C++標準沒有規定原始數據類型(如int)的大小,需要特定大小的類型時,可自訂類型(如int32_t),同時對任何類型使用sizeof()而不假設其大小;
  • 字節序(byte order)按CPU有所不同,特別要注意二進制輸入輸出、reinterpret_cast法;
  • 原始數據和結構類型的地址對齊有差異;
  • 編譯器提供的一些編譯器或平臺專用擴充指令;
  • 避免作應用二進制接口(application binary interface, ABI)的假設,例如調用函數時參數的取值順序在C/C++中沒定義,在C++中也不可隨便假設RTTI/虛表等實現方式。

總括而言,跨平臺C++軟件可在頭文件中用宏檢測編譯器和平臺,再用宏、typedef、自定平臺相關實現等方法去實踐跨平臺,C++標準不會提供這類幫助。

C++程序容易崩潰?

和許多語言相比,C/C++提供不安全的功能以最優化性能,有可能造成崩潰。但要注意,很多運行時錯誤,如向空指針/引用解引用、數組越界、堆棧溢出等,其他語言也會報錯或拋出異常,這些都是程序問題,而不是語言本身的問題。有些意見認為,出現這類運行時錯誤,應該盡量寫入日志并立即崩潰,不該讓程序繼續運行,以免造成更大的影響(例如程序繼續把內存中錯誤的數據覆寫文件)。若要容錯,可按業務把程序分割為多進程,像Chrome或使用fork()的形式。然而,C++有許多機制可以減少錯誤,例如以string代替C字符串;以vectorarray(TR1)代替原始數組(有些實現可在調試模式檢測越界);使用智能指針也能減少一些原始指針的問題。另外,我最常遇到的Bug,就是沒有初始化成員變量,有時會導致崩潰,而且調試版和發行版的行為可能不同。

C++要手動做內存管理?

C++同時提供在堆棧上的自動局部變量,以及從自由存儲(free store)分配的對象。對于后者,程序員需手動釋放,或使用不同的容器和智能指針。 C++程序員經常進一步優化內存,自定義內存分配策略以提升效能,例如使用對象池、自定義的單向/雙向堆棧區等。雖然C++0x還沒加入GC功能,但也可以自行編寫或使用現成庫。此外,C/C++也可以直接使用操作系統提供的內存相關功能,例如內存映射文件、共享內存等。

使用C++常要重造輪子?

我曾參與的C++項目,都會重造不少標準庫已提供的功能,此情況在其他語言中較少出現。我試圖分析個中原因。首先,C++標準庫相對很多語言來說是貧乏的,各開發者便會重復地制造自訂庫。從另一個角度看,C++標準庫是用C++編寫的(很多其他語言不用自身而是用C/C++去編寫庫),在能力和性能上,自訂庫和標準庫并無本質差別;另外,標準庫為通用而設,對不同平臺及多種使用需求作取舍,性能上有所影響,例如EA公司就曾發表自制的EASTL規格,描述游戲開發方面對STL的性能及功能需求的特點;此外,多個C++庫一起使用,經常會因規范不同而引起沖突,又或功能重疊,所以項目可能須自行開發,或引入其他庫的概念或實現(如Boost/TR1/Loki),改寫以符合項目規范。

C++編譯速度很慢?

錯,是非常慢。我認為C++可能是實用程序語言中編譯速度最慢的。此問題涉及C++沿用C的編譯鏈接方式,又加入了復雜的類/泛型聲明和內聯機制,使編譯時間倍增。在C++對編譯方法改革之前(如module提案),可使用以下技巧改善:第一,使用pimpl手法,因性能損耗應用于調用次數不多的類;第二,僅包含必要頭文件,并盡量使用及提供前置聲明版本的頭文件(如iosfwd);第三采用基于接口的設計,但須注意虛函數調用成本;第四,采用unity build,即把多個cpp文件結合在一個編譯單元進行編譯;第五,采用分布式生成系統如IncrediBuild

C++缺乏什么功能?

雖然C++已經非常復雜,但仍缺少很多常見功能。 C++0x作出了不少改善,例如語言方面加入Lambda函數、閉包、類型推導聲明等,而庫方面則加入正則表達式、采用哈希表的unordered_set/unordered_map、引用計數智能指針shared_ptr/weak_ptr等。但最值得留意的是C++0x引入多線程的語法和庫功能,這是C++演進的一大步。然而,模組、GC、反射機制等功能雖有提案,卻未加進C++0x。

C++使用建議

為應用挑選特性集

我同意Stroustrup關于使用C++各種技術的回應:“你可以做,不意味著你必須這么做。(Just because you can do it, doesn't mean that you have to.)” C++充滿豐富的特性,但同時帶來不同問題,例如過分復雜、編譯及運行性能的損耗。一般可考慮是否使用多重繼承、異常、RTTI,并調節使用模版及模版元編程的程度。使用過分復雜的設計和功能,可能會令部分團隊成員更難理解和維護。

為團隊建立編程規范

C++的編碼自由度很高,容易編寫風格迥異的代碼,C++本身也沒有定義一些標準規范。而且,C++的源文件物理構成,較許多語言復雜。因此,除了決定特性集,每個團隊應建立一套編程規范,包括源文件格式(可使用文件模版)、花括號風格。

盡量使用C++風格而非C風格

由于C++有對C兼容的包袱,一些功能可以使用C風格實現,但最好使用C++提供的新功能。最基本的是盡量以具名常量、內聯函數和泛型取代宏,只把宏用在條件式編譯及特殊情況。舊式的C要求局部變量聲明在作用域開端,C++則無此限制,應把變量聲明盡量置于鄰近其使用的地方,for()的循環變量聲明可置于for的括號內。 C++中能加強類型安全的功能應盡量使用,例如避免“萬能”指針void *,而使用個別或泛型類型;用bool而非int表示布爾值;選用4種C++ cast關鍵字代替簡單的強制轉換。

結合其他語言

如前文所述,C++并非適合所有應用情境,有時可以混合其他語言使用,包括用C++擴展其他語言,或在C++程序中嵌入腳本語言引擎。對于后者,除了使用各種腳本語言的專門API,還可使用BoostSWIG作整合。

C++學習建議

C++缺點之一,是相對許多語言復雜,而且難學難精。許多人說學習C語言只需一本K&R《C程序設計語言》即可,但C++書籍卻是多不勝數。我是從C進入C++,皆是靠閱讀自學。在此分享一點學習心得。個人認為,學習C++可分為4個層次:

由于我主要是應用C++,大約只停留于第二、三個層次。然而,C++只是軟件開發的一環而已,單憑語言并不能應付業務和工程上的問題。建議讀者不要強求幾年內“徹底學會C++的知識”,到達第二層左右便從工作實戰中汲取經驗,有興趣才慢慢繼續學習更高層次的知識。雖然學習C++有難度,但也是相當有趣且有滿足感的。

數十年來,C++雖有起伏,但她依靠其使用者而不斷得到頑強的生命力,相信在我退休之前都不會與她分離,也希望更進一步了解她,與她走進未來。


本文原于《程序員》2010年8月刊揭載。

posted on 2010-09-18 10:07 夢在天涯 閱讀(25843) 評論(7)  編輯 收藏 引用 所屬分類: CPlusPlus

評論

# re: C++強大的背后 2010-09-18 10:40 陳梓瀚(vczh)

ABI和RTTI是完全可以假設的。源代碼只要不使用特定API就能跨平臺,只要你在某一個特定平臺上的所有程序(exe和相關的dll)都嚴格使用同一個版本的編譯器編譯,那就不會有問題。C++能跨平臺,但這并不代表平臺之間是兼容的。  回復  更多評論   

# re: C++強大的背后 2010-09-18 10:40 陳梓瀚(vczh)

而且因為C++無敵復雜,所以做出“使用C++”的這個決定是要負責任的,因此程序猿有義務學好C++,而不是到了出事的時候抱怨。做不到就去用別的語言。  回復  更多評論   

# re: C++強大的背后 2010-09-18 11:01 空明流轉

@陳梓瀚(vczh)
跨平臺和平臺兼容并不是一個概念。  回復  更多評論   

# re: C++強大的背后 2010-09-18 15:20 陳梓瀚(vczh)

@空明流轉
恩,我的意思就是,因為不是一個概念,所以ABI和RTTI的不兼容是可以忽略的。程序員有責任將他們編譯成互相兼容的二進制文件。  回復  更多評論   

# re: C++強大的背后 2010-09-18 21:49 lookup

我對EASTL有興趣,誰有這個代碼?  回復  更多評論   

# re: C++強大的背后 2010-09-19 00:18 Milo Yip

雜誌社也想把標題改做C++強大"的"背後,最終都說服了。樓主請高抬貴手……  回復  更多評論   

# re: C++強大的背后 2011-07-07 22:33 放屁阿狗

c++只是個工具,思想是最重要的  回復  更多評論   

公告

EMail:itech001#126.com

導航

統計

  • 隨筆 - 461
  • 文章 - 4
  • 評論 - 746
  • 引用 - 0

常用鏈接

隨筆分類

隨筆檔案

收藏夾

Blogs

c#(csharp)

C++(cpp)

Enlish

Forums(bbs)

My self

Often go

Useful Webs

Xml/Uml/html

搜索

  •  

積分與排名

  • 積分 - 1812202
  • 排名 - 5

最新評論

閱讀排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
      <noscript id="pjuwb"></noscript>
            <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
              <dd id="pjuwb"></dd>
              <abbr id="pjuwb"></abbr>
              久久综合999| 亚洲人成亚洲人成在线观看| 91久久一区二区| 欧美日韩精品一区| 99国内精品久久| 亚洲精品日韩久久| 国产精品久久久久久久午夜片| 亚洲欧美高清| 久久成人这里只有精品| 最新成人av在线| 日韩亚洲欧美一区| 国内精品美女av在线播放| 欧美成人a视频| 欧美午夜电影在线| 老司机免费视频久久| 欧美激情一区二区三区在线视频| 国产精品一区二区男女羞羞无遮挡| 久久精品九九| 理论片一区二区在线| 亚洲一区中文字幕在线观看| 欧美诱惑福利视频| 久久大逼视频| 亚洲黑丝在线| 亚洲综合色丁香婷婷六月图片| 国产偷国产偷亚洲高清97cao| 欧美a级大片| 欧美特黄一级大片| 久久综合狠狠综合久久综青草| 欧美精品一区二区三区蜜桃 | 性色一区二区三区| 亚洲人成亚洲人成在线观看图片| 亚洲视频www| 亚洲激情午夜| 亚洲视频大全| 免费亚洲一区| 欧美日韩精品三区| 很黄很黄激情成人| 99re在线精品| 亚洲福利一区| 欧美一二三视频| 亚洲视频精选在线| 欧美高清一区| 欧美~级网站不卡| 国产欧美韩国高清| 亚洲视频精选在线| 99视频有精品| 免费在线国产精品| 美女91精品| 国产一区视频在线看| 亚洲一区二区欧美| 亚洲午夜高清视频| 欧美日韩国产不卡在线看| 欧美国产欧美亚州国产日韩mv天天看完整| 国产精品一区在线观看你懂的| 亚洲九九九在线观看| 亚洲日本欧美在线| 欧美aⅴ99久久黑人专区| 麻豆精品一区二区综合av| 国产视频亚洲| 久久激情五月激情| 国产色爱av资源综合区| 欧美日韩一区二区高清| 91久久久在线| 99香蕉国产精品偷在线观看| 亚洲欧洲三级| 欧美精品在线一区| 亚洲精品久久久久久久久久久久 | 牛牛国产精品| 在线观看日韩欧美| 久久人91精品久久久久久不卡| 久久激情中文| 伊人色综合久久天天五月婷| 久久精品国产亚洲高清剧情介绍| 久久一区二区精品| 亚洲国产综合在线看不卡| 欧美不卡高清| 一本不卡影院| 欧美在线亚洲在线| 在线视频观看日韩| 欧美精品一区在线发布| 一区二区三区你懂的| 欧美在线亚洲在线| 亚洲第一福利视频| 欧美日本高清视频| 亚洲视频在线观看视频| 久久精品国产99精品国产亚洲性色| 国产一区二区在线观看免费| 久久久999成人| 亚洲欧洲一区二区天堂久久| 亚洲午夜精品网| 国产亚洲精品激情久久| 男人插女人欧美| 亚洲一级特黄| 欧美国产视频一区二区| 亚洲性色视频| 亚洲国产精品成人va在线观看| 欧美激情综合五月色丁香| 亚洲欧美日韩国产一区二区| 男人插女人欧美| 亚洲欧美激情一区| 亚洲国产成人av| 国产精品久久久久一区二区| 久久久久国产精品麻豆ai换脸| 91久久国产精品91久久性色| 欧美影院视频| 宅男噜噜噜66国产日韩在线观看| 国产欧美在线视频| 欧美日韩成人一区| 久久精品首页| 亚洲欧美日韩国产成人| 亚洲精选一区| 免费日韩精品中文字幕视频在线| 亚洲永久在线| 亚洲乱码国产乱码精品精可以看| 国产精品久久久91| 欧美日韩高清区| 蜜臀av一级做a爰片久久| 午夜精品久久久久久久久久久久| 亚洲日本成人女熟在线观看| 久久婷婷综合激情| 欧美一区二区| 亚洲永久免费观看| 一区二区欧美亚洲| 亚洲精品乱码久久久久久按摩观 | 欧美国产日韩xxxxx| 欧美在线免费视频| 亚洲一区二区三| 99国产麻豆精品| 亚洲精品久久久蜜桃 | 久久久999精品| 午夜影院日韩| 亚洲中字在线| 亚洲欧美美女| 午夜精品成人在线视频| 亚洲调教视频在线观看| 一本久道久久综合中文字幕| 一区二区在线观看视频| 欧美精选在线| 久久久久国产精品一区三寸| 午夜伦理片一区| 午夜一级在线看亚洲| 亚洲午夜羞羞片| 亚洲与欧洲av电影| 亚洲影院在线| 亚洲欧美日韩一区二区| 亚洲中字黄色| 久久激情网站| 免费久久久一本精品久久区| 免费日韩av电影| 欧美精品免费播放| 欧美日韩中文字幕在线视频| 国产精品都在这里| 国产欧美精品一区aⅴ影院| 国产一区二区高清视频| 一区二区三区在线视频播放| 亚洲风情在线资源站| 亚洲另类一区二区| 亚洲免费在线观看| 久久蜜桃香蕉精品一区二区三区| 久久夜色精品| 91久久精品国产91性色| 夜夜嗨av一区二区三区中文字幕| 在线亚洲一区二区| 久久国产欧美精品| 美女视频网站黄色亚洲| 欧美日韩在线另类| 国精品一区二区三区| 亚洲成人原创| 亚洲永久免费精品| 免费视频一区| 一区二区久久久久| 久久免费的精品国产v∧| 欧美韩国一区| 国产亚洲一区二区三区| 亚洲人成毛片在线播放女女| 亚洲自拍啪啪| 免费国产一区二区| 亚洲一区二区免费视频| 蜜臀久久久99精品久久久久久| 欧美性色aⅴ视频一区日韩精品| 国产午夜亚洲精品不卡| 99国产精品自拍| 久久尤物视频| 亚洲夜间福利| 欧美国产高潮xxxx1819| 国产日韩一区二区| 亚洲天堂成人在线观看| 免费日韩av电影| 午夜亚洲福利| 欧美视频在线观看 亚洲欧| 国产亚洲精品福利| 亚洲欧美在线高清| 91久久在线视频| 久久久99爱| 国产日产亚洲精品| 亚洲一区999| 亚洲精品在线一区二区| 久久久亚洲欧洲日产国码αv| 国产精品日韩欧美一区二区三区| 日韩视频在线一区|