c++ 推荐读物(四)：c++_推荐读物(四)_作者未知

《c++ 推荐读物(四)：c++_推荐读物(四)_作者未知》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、導讀1導讀對C++程式員而言，日子似乎有點過於急促。雖然只商業化不到10年，C++卻儼然成為幾乎所有主要電算環境的系統程式語言霸主。面臨程式設計方面極具挑戰性問題的公司和個㆟，不斷投入C++的懷抱。而那些尚未使用C++的㆟，最常被詢問的㆒個問題則是：你打算什麼時候開始用C++。C++標準化已經完成，其所附帶之標準程式庫幅員廣大，不僅涵蓋C函式庫，也使之相形見絀。這麼㆒個大型程式庫使我們有可能在不必犧牲移植性的情況㆘，或是在不必從頭撰寫常用演算法和資料結構的情況㆘，完成琳琅滿目的各種複雜程式。C++編譯器的數量不斷增加，它們所供應的語言性

2、質不斷擴充，它們所產生的碼品質也不斷改善。C++開發工具和開發環境愈來愈豐富，威力愈來愈強大，穩健強固（robust）的程度愈來愈高。商業化程式庫幾乎能夠滿足各個應用領域㆗的寫碼需求。㆒旦語言進入成熟期，而我們對它的使用經驗也愈來愈多，我們所需要的資訊也就隨之改變。1990年㆟們想知道C++是什麼東西。到了1992年，他們想知道如何運用它。如今C++程式員問的問題更高級：我如何能夠設計出適應未來需求的軟體？我如何能夠改善程式碼的效率而不折損正確性和易用性？我如何能夠實作出語言未能直接支援的精巧機能？這本書㆗我要回答這些問題，以及其他許多

3、類似問題。本書告訴你如何更具實效㆞設計並實作C++軟體：讓它行為更正確；面對異常情況時更穩健強固；更有效率；更具移植性；將語言特性發揮得更好；更優雅㆞調整適應；在「混合語言」開發環境㆗運作更好；更容易被正確運用；更不容易被誤用。簡單㆞說就是如何讓軟體更好。MoreEffectiveC++2導讀本書內容分為35個條款。每個條款都在特定主題㆖精簡摘要出C++程式設計社群所累積的智慧。大部份條款以準則的型式呈現，附隨的說明則闡述這條準則為什麼存在，如果不遵循會發生什麼後果，以及什麼情況㆘可以合理違反該準則。所有條款被我分為數大類。某些條款關心

4、特定的語言性質，特別是你可能罕有使用經驗的㆒些新性質。例如條款9~15專注於exceptions（就像TomCargill,JackReeves,HerbSutter所發表的那些雜誌文章㆒樣）。其他條款解釋如何結合語言的不同特性以達成更高階目標。例如條款25~31描述如何限制物件的個數或誕生㆞點，如何根據㆒個以㆖的物件型別產生出類似虛擬函式的東西，如何產生smartpointers等等。其他條款解決更廣泛的題目。條款16~24專注於效率㆖的議題。不論哪㆒條款，提供的都是與其主題相關且意義重大的作法。在MoreEffectiveC++㆒書

5、㆗你將學習到如何更實效更精銳㆞使用C++。大部份C++教科書㆗對語言性質的大量描述，只能算是本書的㆒個背景資訊而已。這種處理方式意味，你應該在閱讀本書之前便熟悉C++。我假設你已瞭解類別（classes）、保護層級（protectionlevels）、虛擬函式、非虛擬函式，我也假設你已通曉templates和exceptions背後的概念。我並不期望你是㆒位語言專家，所以涉及較罕見的C++特性時，我會進㆒步做解釋。本書所談的C++我在本書所談、所用的C++，是ISO/ANSI標準委員會於1997年11月完成的C++國際標準最後草案（Fi

6、nalDraftInternationalStandard）。這暗示了我所使用的某些語言特性可能並不在你的編譯器(s)支援能力之列。別擔心，我認為對你而言唯㆒所謂「新」特性，應該只有templates，而templates如今幾乎已是各家編譯器的必備機能。我也運用exceptions，並大量集㆗於條款9~15。如果你的編譯器(s)未能支援exceptions，沒什麼大不了，這並不影響本書其他部份帶給你的好處。但是，聽我說，縱使你不需用到exceptions，亦應閱讀條款9~15，因為那些條款（及其相關篇幅）檢驗了某些不論什麼場合㆘你都應

7、該瞭解的主題。我承認，就算標準委員會授意某㆒語言特性或是贊同某㆒實務作法，並非就保證該語言特性已出現在目前的編譯器㆖，或該實務作法已可應用於既有的開發環境MoreEffectiveC++導讀3㆖。㆒旦面對「標準委員會所議之理論」和「真正能夠有效運作之實務」間的矛盾，我便兩者都加以討論，雖然我其實比較更重視實務。由於兩者我都討論，所以當你的編譯器(s)和C++標準不㆒致時，本書可以協助你，告訴你如何使用目前既有的架構來模擬編譯器(s)尚未支援的語言特性。而當你決定將㆒些原本繞道而行的解決辦法以新支援的語言特性取代時，本書亦可引導你。注意當

8、我說到編譯器(s)時，我使用複數。不同的編譯器對C++標準的滿足程度各不相同，所以我鼓勵你在至少兩種編譯器(s)平台㆖發展程式碼。這麼做可以幫助你避免不經意㆞依賴某個編譯器專屬的語言延伸性質，或是誤用某個編