Effective C中文版第三版 高清PDF總結(jié)[共97頁]

Effective C+閱讀筆記Effective C+閱讀筆記1原則3：盡可能使用const4原則5：了解C+默默編寫并調(diào)用哪些函數(shù)6原則6：若不想使用編譯器自動生成的函數(shù)，就應(yīng)該明確拒絕8原則7：為多態(tài)基類聲明virtual析構(gòu)函數(shù)11原則8：別讓異常逃離析構(gòu)函數(shù)15原則9：絕不在構(gòu)造和析構(gòu)過程中調(diào)用virtual函數(shù)16原則10：令operator=返回一個reference to *this19原則11：在operator=中處理“自我賦值”19原則12：復(fù)制對象時勿忘其每一個成分21原則13：以對象管理資源22原則14：在資源管理類中小心COPYING行為24原則15：在資源管理類中提供對原始資源的訪問25原則16：成對使用new和delete時要采用相同形式27原則17：以獨立語句將newed對象置入智能指針28原則18：讓接口容易被正確使用，不易被誤用29原則19：設(shè)計class猶如設(shè)計type30原則20：寧以引用傳遞代替值傳遞31原則21：必須返回對象時，別妄想返回其引用32原則22：將成員變量聲明為private33原則23：寧以非member、非friend替換member函數(shù)34原則24：若所有參數(shù)皆需要類型轉(zhuǎn)換，請為此采用非member函數(shù)35原則25：考慮寫出一個不拋出異常的swap函數(shù)37原則26：盡可能延后變量定義式的出現(xiàn)時間39原則27：盡量少做類型轉(zhuǎn)換動作40原則28：避免返回handles指向?qū)ο蟮膬?nèi)部成分43原則29：為“異常安全”而努力是值得的45原則30：透徹了解inline（內(nèi)聯(lián)）的里里外外48原則31：將文件間的變異依存關(guān)系降至最低50原則32：確定你的public繼承塑造出了IS-A關(guān)系53條款33：避免屏蔽繼承而來的名字54原則34：區(qū)分接口繼承和實現(xiàn)繼承55原則35：考慮virtual函數(shù)以外的其他選擇57原則36：決不能重新定義繼承而來的非virtual函數(shù)60原則37：絕不重新定義繼承而來的缺省參數(shù)值62原則38：通過復(fù)合塑造出HAS-A關(guān)系或者根據(jù)某物實現(xiàn)出來63原則39：明知而審慎地使用PRIVATE繼承64原則40：明智而審慎地使用多重繼承69原則41：了解隱式接口和編譯期多態(tài)71原則42：了解typename的雙重意義72原則43：學(xué)習(xí)處理模版化基類內(nèi)的名稱74原則44：將與參數(shù)無關(guān)的代碼抽離templates76原則45：運用成員函數(shù)模版接受所有兼容類型78原則46：需要類型轉(zhuǎn)換時請為模版定義非成員函數(shù)80原則47：請使用traits classes表現(xiàn)類型信息82原則48：認(rèn)識template元編程85原則49：了解new-handler的行為87原則50：了解new和delete的合理替換時機90條款51：編寫new和delete時需固守常規(guī)92原則52：寫了placement new也要寫placement delete94原則54：不要忽視編譯器的警告95原則54：讓自己熟悉包括TR1在內(nèi)的標(biāo)準(zhǔn)程序庫96原則55：讓自己熟悉Boost97本來是寫在百度空間的，但是不知道咋回事百度博客中圖片看不到了，所以百度博客的不穩(wěn)定性可見一斑。于是我決定將我的領(lǐng)會和感受寫在自己的云盤里面。雖好也弄個目錄啥的，最后再整車成PDF格式的。這個標(biāo)準(zhǔn)我就參考我研究生期間論文的格式吧。原則3：盡可能使用constEffective C+里面第3條原則是盡量使用const。其原因是防止無意中更改而本來不應(yīng)該更改的變量。本條款也提到const成員函數(shù)的重要性，原因之一就是只有const函數(shù)才能用來操縱const對象。而所謂const對象就像下圖所示的這樣：有的時候會遇到在const函數(shù)中更改非const成員變量的情況，這個時候就要用到mutable關(guān)鍵字了。如果一個成員變量被mutable修飾，那么它在const函數(shù)中仍然可以被修改，但是前提是該成員變量是非const成員。還有一種情況就是為了防止代碼重復(fù)，比如兩個函數(shù)實現(xiàn)了同樣的功能只是類型不同而已，這樣就會導(dǎo)致兩段幾乎相同的代碼段，這無疑會增加編譯時間、維護和代碼膨脹等風(fēng)險。在本原則的有關(guān)敘述中，作者采用了強制類型轉(zhuǎn)換來解決之，雖然作者本身在大多數(shù)情況下并不提倡做法。為了給用戶一個一目了然的接口，一看就知道那些成員函數(shù)可以操縱const對象而哪些不能，作者建議在類中明確將那些不改變對象的成員函數(shù)聲明為const函數(shù)，雖然const成員函數(shù)可以使用非const成員變量，但是遵守這一原則會給客戶帶來極大的便利。因為const成員函數(shù)不更改對象，這就防止了由于誤操作而帶來的問題，因為最好用非const成員函數(shù)去調(diào)用const的實現(xiàn)，說白了就是直接return這個const成員函數(shù)，只不過需要對作為這個return的表達式的const成員函數(shù)進行一下強制類型轉(zhuǎn)換使其成為非const型的。所以，在這里不得不提一下純粹的C+的強制類型轉(zhuǎn)換。關(guān)鍵在static_cast<typename>(value)是純粹的C+強制類型轉(zhuǎn)換的關(guān)鍵詞和用法，它的使用頻率是最高的。const_cast<typename>(value)是用來消除const屬性時用的。不過它不能用于基本類型。reinterpret_cast<typename>(value)它用于無關(guān)類型之間的轉(zhuǎn)換。dynamic_cast<typename>(value)用于父子類指針之間的轉(zhuǎn)換。在C+語言中只有這4中強制類型轉(zhuǎn)換。原則5：了解C+默默編寫并調(diào)用哪些函數(shù)這一篇博客是Effective C+中第5個條款。但現(xiàn)在感覺我還沒太理解它到底說了什么，所以想寫寫博客，萬一寫著寫著就明白了呢。首先在這里敘述一個機制，那就是空類，在默認(rèn)的情況下，編譯器會給它自動生成默認(rèn)的構(gòu)造函數(shù)、拷貝構(gòu)造函數(shù)、拷貝賦值操作符=和析構(gòu)函數(shù)。并且他們都是public的和inline的。它與下面這個類是一樣的。至于這些成員函數(shù)和操作符是干啥用的，我在前邊的博文中闡述過了。其中，默認(rèn)的構(gòu)造函數(shù)負(fù)責(zé)調(diào)用父類和非static的構(gòu)造函數(shù)和析構(gòu)函數(shù)。如上圖可見編譯器自動生成的析構(gòu)函數(shù)是非virtual的，如果父類中本身存在virtual的析構(gòu)函數(shù)，編譯器就不會自動產(chǎn)生非virtual的析構(gòu)函數(shù)了。而默認(rèn)的copy構(gòu)造函數(shù)和copy賦值操作符只是copy非static成員到目標(biāo)對象。不過，如果你手動寫了它們中的一些，編譯器就只會自動生成你沒寫的。比如你只寫了構(gòu)造函數(shù)，那么其他的東西編譯器負(fù)責(zé)給你自動生成。至于說copy構(gòu)造函數(shù)和copy賦值操作符的用法我以前的博文有提到過。而copy構(gòu)造函數(shù)總是層層調(diào)用底層的copy構(gòu)造函數(shù)來進行賦值，比如說copy構(gòu)造函數(shù)要copy一個string類型的變量，那么它就會調(diào)用string的copy構(gòu)造函數(shù)，實在沒辦法了，它再自己進行賦值操作。其實本原則著重討論的是在什么情況下編譯器不會自動生成這些東東。對于默認(rèn)的構(gòu)造函數(shù)而言，當(dāng)你手動寫了一個構(gòu)造函數(shù)的話，編譯器就不會再費那個勁了。而對于copy賦值操作符呢也是有自動生成條件的，那就是這個copy賦值操作符確實有存在的意義，并且它能在使用場合能正確工作，否則除非你自己手動寫一個，要不然編譯器是不會給你生成這些東東的。而在書中作者舉了2個例子1個是引用，另一個是const常量，這兩者所指的對象都是不能更改的，那你非要給它們賦值，那肯定會導(dǎo)致copy賦值操作符的失敗。書中還舉個1個例子，一般情況下父類中如果有copy賦值操作符，在子類中編譯器是不會再給自動生成copy賦值操作符，直接使用父類的就好了，因為編譯器認(rèn)為子類的copy賦值操作符是要能夠處理父類的賦值操作的。所以如果你此時把父類的copy賦值操作符設(shè)置為private的，那么你就沒有copy賦值操作符可用了，除非你自己在子類中寫一個。原則6：若不想使用編譯器自動生成的函數(shù)，就應(yīng)該明確拒絕這是Effective C+中第6個原則，在某些情況下你不想讓某些類的對象被拷貝，那么在這種情況下即使你不寫copy構(gòu)造函數(shù)和copy賦值操作符編譯器也會為你生成，那么你不得不自己寫它們倆。而你又不希望別人調(diào)用它們，所以這時你要將它們聲明為private類型。一旦你寫了，編譯器就不會自動調(diào)用父類的copy構(gòu)造函數(shù)和copy賦值操作符。即便這樣本類內(nèi)部成員函數(shù)和友元函數(shù)還是可以調(diào)用它們，該如何是好？辦法就是你只聲明這些函數(shù)而不去實現(xiàn)，沒有實現(xiàn)就自然沒有功能了，而既然實際上沒用，你甚至連形參都可以省略，只在形參列表中寫個形參類型即可，就像下圖類的定義所示的這樣：其中的幾個函數(shù)實現(xiàn)如下所示：從上圖可見，copy構(gòu)造函數(shù)和copy賦值操作符都沒有實現(xiàn)。在主程序中是如下調(diào)用的：運行結(jié)果如下所示：出現(xiàn)了錯誤提示，說copy構(gòu)造函數(shù)無法解析?，F(xiàn)在我把copy構(gòu)造函數(shù)和copy賦值操作符都注釋掉。在運行得如下結(jié)果：而本思想只在闡述如果你不想讓編譯器為你自動生成函數(shù)，你就要自己手寫。原則7：為多態(tài)基類聲明virtual析構(gòu)函數(shù)這是Effective C+中第7條原則，其內(nèi)容是在具有多態(tài)用途的父類中應(yīng)該使用virtual析構(gòu)函數(shù)。首先要知道啥是多態(tài)。我就好說直白的，顯得沒有深度的東西。多態(tài)的一種體現(xiàn)就是通過父類的指針指向不同的子類來實現(xiàn)不同的功能，從而達到接口重用的目的。在這種情況下用作多態(tài)的父類往往具有至少一個virtual成員函數(shù)留給子類來實現(xiàn)。好了，現(xiàn)在鋪墊完畢了，來說正題，為啥要有一個virtual析構(gòu)函數(shù)呢？那是因為如果沒有這樣一個virtual析構(gòu)函數(shù)的話，子類的析構(gòu)函數(shù)就不會被調(diào)用，那么對象的子類部分不會被析構(gòu)，那么就會造成資源的泄露?，F(xiàn)在來看下面的例子：derived繼承了base，并且base中并沒有virtual析構(gòu)函數(shù)，那么調(diào)用過程如下所示：運行結(jié)果如下所示：從這個結(jié)果可以看到父類的析構(gòu)函數(shù)執(zhí)行了，說明對象的父類部分所占資源已經(jīng)被釋放，但是子類的析構(gòu)函數(shù)并未調(diào)用這說明對象中子類部分所占資源并未得到釋放。但是如果在父類中加上一個virtual析構(gòu)函數(shù)的話就不一樣了。同樣的調(diào)用過程，運行結(jié)果如下所示：這說明對象的子類部分所占資源也被釋放掉了。在這里再說點別的，一般來講作為要被繼承的父類的類中至少含有一個virtual的成員函數(shù)留給子類去實現(xiàn)。而如果某類中一個virtual成員函數(shù)都沒有的話，在很大程度上說明了該類不會被作為父類而存在，在這種情況下不應(yīng)該把其析構(gòu)函數(shù)設(shè)為virtual的。為啥呢？這與C+中virtual本身的實現(xiàn)機制有關(guān)，因為這樣的類的對象必須要攜帶一個表，這個表叫vtbl，所以本來沒必要多帶這么個表，但是你非要多出一個來占個空間，這就是占個茅坑不拉屎的表現(xiàn)啊。所以不準(zhǔn)備被繼承的類是沒有必要設(shè)置virtual析構(gòu)函數(shù)的。在這里在介紹一種情況，當(dāng)你希望在virtual類中把析構(gòu)函數(shù)設(shè)為virtual的時候，應(yīng)該吧析構(gòu)函數(shù)設(shè)為純virtual函數(shù)，并且給與空的實現(xiàn)，如下圖所示：為啥要這樣做呢？因為析構(gòu)函數(shù)調(diào)用順序是從沒有子類的子類那里的析構(gòu)函數(shù)逐層調(diào)用父類的析構(gòu)函數(shù)，所以如果這個純virtual函數(shù)沒有實現(xiàn)的話，編譯器就會報錯。這個原則簡而言之就是，只有作為多態(tài)用途的父類才有必要使用virtual析構(gòu)函數(shù)，其他的就是畫蛇添足。另外，處于繼承機制的類對象包含了它所能涉及到的最低層次及其以上的所有層次的成分。原則8：別讓異常逃離析構(gòu)函數(shù)這是Effective C+的第八條原則。主要說的是程序出現(xiàn)的異常不要從析構(gòu)函數(shù)這里漏掉，也就是說析構(gòu)函數(shù)應(yīng)該承擔(dān)起攔截異常的責(zé)任才行。如果異常越過了析構(gòu)函數(shù)這一關(guān)，流竄到其他地方去，那么就會造成程序提早結(jié)束或者未知的風(fēng)險，這個后果就很嚴(yán)重了。對付這種情況通常有兩種簡單粗暴的手段：1、在析構(gòu)函數(shù)內(nèi)發(fā)現(xiàn)異常，立刻捕捉到并且結(jié)束整個程序；2、在析構(gòu)函數(shù)中發(fā)現(xiàn)異常，立刻捕捉到并將其扼殺，掩人耳目，繼續(xù)執(zhí)行程序。其中第一種手段比第二種手段要好，這是為啥呢？因為方法1直接結(jié)束程序，其結(jié)果是可預(yù)料的，不會造成太大破壞。而方法2你這個異常是終止了，但是程序中其他部分與這個功能相關(guān)的勢必會造成影響，也許還會因此帶來其他異常的連鎖反應(yīng)，這個就不好辦了。不過以上這兩種方法都沒能去正面處理出現(xiàn)的異常，所以這兩種方法都不提倡。書中給出的解決方案是，再創(chuàng)建一個類用來處理異常，在這個類中有一個成員函數(shù)專門用來處理原來的類中的異常。而這個成員函數(shù)是調(diào)用原類中的異常處理來完成的，這實際上就是變相的讓原類自己處理異常，這是第一道關(guān)卡。然后異常處理類的析構(gòu)函數(shù)中也有一份處理異常的代碼，這部分是異常處理類自己的，這是第二道關(guān)卡。這個就是雙保險，如果說在第二道關(guān)卡仍然不能有效處理異常，那沒辦法了，只能強行關(guān)閉程序了。再總結(jié)一下本原則就是無論如何也不能讓異常突破析構(gòu)函數(shù)這一關(guān)。原則9：絕不在構(gòu)造和析構(gòu)過程中調(diào)用virtual函數(shù)這是Effective C+中的第9條原則。簡單的來說，如果你在父類的構(gòu)造函數(shù)中調(diào)用了虛擬函數(shù)，那么子類的成員就會始終處于未初始化的狀態(tài)，這樣對象的子類成分就會出現(xiàn)不可預(yù)知的行為，這是非常危險的。那么這是為什么呢？在繼承體系當(dāng)中，你聲明了一個子類對象，那么這個子類對象其實是很復(fù)雜的，它包含了子類所有父類的成分。而這些成分是要一層一層的進行初始化的，其順序是按照類的繼承層次從上而下進行的，即從最遠(yuǎn)的那個父類到最近的那個父類，然后是本類的初始化。而C+的機制又是只有在父類成分初始化完畢以后才去處理子類成分的初始化工作，換句話說，如果父類的成分沒有初始化完畢，它壓根就不會去管子類的初始化工作。因為你在父類的構(gòu)造函數(shù)中調(diào)用了虛擬函數(shù)，而這個虛擬函數(shù)一般在父類中是不進行實現(xiàn)的。鄙人以為，一個函數(shù)之所以被調(diào)用肯定是因為這個函數(shù)是有一定的功能實現(xiàn)的，要不你調(diào)用它干嗎？我想C+的構(gòu)造函數(shù)也是這么想的。但是，你現(xiàn)在非要在本來用于初始化的構(gòu)造函數(shù)中去調(diào)用一個沒法初始化virtual函數(shù)，C+就認(rèn)為這個對象的父類成分還沒有初始化完畢，現(xiàn)在不能去初始化子類成分。所以，即使你現(xiàn)在聲明了一個子類對象，子類中的成分還是沒有得到初始化，所以就會出現(xiàn)不可預(yù)知的后果。C+對未定位的成員變量是采取無視的態(tài)度的，因為還沒輪到你，你給我一邊涼快去。在構(gòu)造函數(shù)期間無視，在析構(gòu)函數(shù)期間也是無視。而析構(gòu)的順序又是先子類再父類，因為對象的子類成分被無視，只有父類成分被析構(gòu)，所以那些未定義的成員變量自始至終都是未定義的，你也不知道它們最終會怎樣。為了證實這一點請看下面的例子：運行結(jié)果是這樣的：看到這個結(jié)果，我不得不說現(xiàn)在的編譯器已經(jīng)很智能了，它直接把它攔下來了。在介紹與本原則有關(guān)的內(nèi)容時，作者舉了一個應(yīng)用場景。那就是當(dāng)類中有多個不同版本的構(gòu)造函數(shù)，它們的共同的初始化代碼都統(tǒng)一放到一個初始化成員函數(shù)里面了，并且這個初始化成員函數(shù)調(diào)用了一個virtual成員函數(shù)，并且這個virtual成員函數(shù)會有一定的實現(xiàn)代碼。當(dāng)你建立子類對象時卻調(diào)用了錯誤的virtual成員函數(shù)。在此作者并沒有詳細(xì)地解釋是為什么，但他給出了一種解決辦法。那就是在子類的構(gòu)造函數(shù)的初始化成員列表中調(diào)用父類的構(gòu)造函數(shù)去初始化對象中父類的部分，當(dāng)然了，這時父類中的那個virtual函數(shù)你要改成非virtual函數(shù)了。在這里作者使用了一個技巧，他不是在成員初始化列表直接把父類成分所需的東西直接給它，而是通過一個輔助函數(shù)返回一個值給父類進行初始化，這樣寫比較方便也比較可讀。而且，這個輔助函數(shù)的是一個static類型。static類型的成員函數(shù)是靜態(tài)成員函數(shù)，它的類的對象實例化之前就已經(jīng)被實例化，換句話說它跟類中其他的成員不發(fā)生關(guān)系。另外，子類對象的父類成分是在子類成分之前先被實例化，而在子類對象實例化的中間也就是父類成分正在實例化，還沒輪到子類成分實例化之前，子類中的成員函數(shù)啥的是未定義的，也就工作不了。而此時static成員函數(shù)卻能工作，這有助于對象中父類成分的實例化，所以把此輔助函數(shù)設(shè)置為static類型。原則10：令operator=返回一個reference to *this原則11：在operator=中處理“自我賦值”在這篇博文里面我打算寫兩個Effective C+中的原則，因為第一個原則太短了?，F(xiàn)在介紹第一個原則：條款10，此條款旨在說明在你自己編寫的賦值操作符=一定要返回該左值的引用。具體來說就是返回*this。這很好解釋，因為this是指向本對象的指針，那么*this就是該對象的本身實體了。而你現(xiàn)在返回的只不過是該實體的一個代表符號而已?，F(xiàn)在一般的賦值操作符都采用這個原則，雖然不是強制的，但是大家都遵守。下面來對條款11做一些介紹。條款11的內(nèi)容很簡單，就是一定要妥善處理賦值操作符=的自我賦值問題，就是自己給自己賦值的情況。那么這又是為什么呢？因為在某些時候你要編寫用來管理資源的類，那你知道一個資源不用了就要釋放掉，以便留給下一個需要該資源的對象。不過，這是很合理的。但是，假設(shè)當(dāng)前占用該資源的對恰好是用來賦值的右值，也就是它倆其實是一個東東。如果還是按照上面處理的話，就會出現(xiàn)被用來賦值的右值實際上已經(jīng)啥實質(zhì)內(nèi)容都沒有了，this指針指向了NULL，那就會發(fā)生錯誤。那么怎樣處理這種情況呢？第一種方法很簡單，那就是在賦值操作符的實現(xiàn)中最先判斷一下賦值的對象和被賦值的對象是不是一個，即if(this=&obj)。不過這種方法不好，因為這需要額外寫出一條語句，這無疑會增加運行時間。所以實際上采用的辦法就是所謂的COPY and SWAP方法。什么意思呢？首先賦值一份右值，生成一個COPY，然后用*this與這個COPY進行SWAP，那么就可以完美解決自我賦值的問題。因為既然是COPY那么原來那個右值就沒有改變，而this原本是空的，它和那個COPY交換以后，那個COPY就變成了NULL，而this的內(nèi)容就成了COPY，也就是原來的那個右值的值了。還有一種方法就是直接利用賦值操作符重載函數(shù)的傳參機制是傳值這一特性，直接傳進來一個COPY。該方法可行，但是作者不提倡，它說這樣做的話清晰性變差了，我的這個清晰性大概就是可讀性吧。不過，我倒覺得沒啥。他又說這種方法有時候可能更高效。原則12：復(fù)制對象時勿忘其每一個成分這個原則是Effective C+中第12個原則，這原則主要涉及到兩個方面：1、自定義的COPY構(gòu)造函數(shù)和賦值操作符一定要卻把本類中的所有成員，包括新增加的成員和父類的所有成員都要復(fù)制過來。2、不要嘗試COPY構(gòu)造函數(shù)和賦值操作符進行互相調(diào)用。第1點沒啥好討論的，現(xiàn)在來著重討論第2點。咱們只討論一種情況，就是copy賦值操作符去掉用copy構(gòu)造函數(shù)的情況。因為copy構(gòu)造函數(shù)本身就已經(jīng)把復(fù)制了一個副本，換句話說它自身已經(jīng)生成了一個嶄新的對象。而copy賦值操作符是把傳進來的對象賦給這個嶄新的對象，那不就是試圖在構(gòu)造一個已經(jīng)存在的對象了嗎，這很荒謬。同理copy構(gòu)造函數(shù)去掉用copy賦值操作符同樣荒謬。所以作者建議方法是把它們共同的代碼放到第3個函數(shù)中，通常這個函數(shù)被命名為init。原則13：以對象管理資源這是Effective C+中提到的第13個原則。資源的管理這一主題從宏觀上來講就是你申請了資源，就一定要釋放。你不釋放會造成內(nèi)存泄露，資源泄露，你釋放多了有可能導(dǎo)致程序行為異常。所以簡而言之就是你申請了多少個資源就釋放多少個資源就行了。可是你在編程的過程難免會忘掉或者沒有處理好資源釋放的過程，那么本原則就是告訴你如何去控制資源的釋放的。作者的經(jīng)驗之談就是以對象作為資源的載體進行傳遞以代替用單個語句去實現(xiàn)資源的管理過程。因為在這個過程中，程序流說不定就可能被return拐走，被作為異常拋出，被continue或者break跳過，當(dāng)然還有那幾乎被摒棄的goto語句等等，而沒有到達delete。因為對象本身有構(gòu)造函數(shù)和析構(gòu)函數(shù)，而且它會在對象的生存期末尾自動調(diào)用析構(gòu)函數(shù)來釋放資源，從而不會造成資源泄露的情況。其實，我感覺此條款著重強調(diào)的是釋放資源的重要性，但是它也強調(diào)在取得資源的時候馬上就進行初始化。而對于操縱對象作者又極力推薦了兩種智能指針：auto_ptr，shared_ptr。這兩個指針都會在資源使用結(jié)束后自動銷毀它們，而不用你管。auto_ptr的簡單用法如下：它有個特性，那就是一旦用這種指針指向某資源，那就不能有多個auto_ptr再去指向它了。如果已經(jīng)有一個指針指向了某資源，你再用新指針指向這個指針的話，就指針就被自動設(shè)為NULL。shared_ptr叫“引用計數(shù)型指針”，它與auto_ptr的不同之處在于它能記錄到底有多少個對象指向某資源，但是它無法解決環(huán)狀引用，就是兩個沒用的指針互指。不過，一般情況下，智能指針里面裝的都是一個函數(shù)，這個函數(shù)返回一個對象的引用，并完成該對象的初始化工作。tr1:shared_ptr<Base> ptb(factory();其中factory()函數(shù)負(fù)責(zé)初始化并返回管理資源的對象的引用。原則14：在資源管理類中小心COPYING行為這是Effective C+中第14個原則。本原則闡述了資源管理類往往遵循RA原則，就是“資源在構(gòu)造期間獲得，在析構(gòu)期間釋放”。因為是要用對象來承載資源的，而本原則考慮的是如果對這種對像進行復(fù)制要怎樣處理。因為這種管理資源的對象在復(fù)制的過程中很少COPY所謂的“同步化基礎(chǔ)器物”，據(jù)我的理解就是構(gòu)造和析構(gòu)函數(shù)這里的問題，當(dāng)然我的理解可能不對。所以可能出現(xiàn)COPY過來的資源不能及時釋放掉。作者給出的4個解決上述問題的辦法：1、壓根就不復(fù)制資源管理對象，這就不會有問題了嘛；2、采用“引用計數(shù)法”，即要達到COPY多少對象就釋放多少對象。這往往要用到shared_ptr；3、COPY要拷貝的全面，即在該類的所有繼承體系中的類的成分都COPY過來；4、保持資源的獨一性，即它不會有多分COPY，而這往往要用到auto_ptr。原則15：在資源管理類中提供對原始資源的訪問這是Effective C+中第15條原則，我感覺非常抽象，理解起來很費勁，那我就邊理解邊寫博客吧。首先你要明白啥叫原始資源，其實確切的概念我也說不準(zhǔn)，但是你可以簡單地理解為被資源管理類管理的資源。管理資源要使用資源管理類，通常這個類被稱為RA類，在理想的情況下，你總是試圖使用RA類來進行資源管理，但是世事無常，總有一些API（Application Programming Interface）會直接調(diào)用原始資源，它們會繞過RA類，而這不符合你的原則，而你又不得不去用。那么本原則會叫你處理這種情況的一些方法。作者舉了兩個例子：1、通過傳遞資源管理類的對象的某些方法間接傳遞一份原始資源的COPY，這樣真正的原始資源不會得到改變。那就需要RA類提供一個接口使對象能夠暴露出其內(nèi)所含的原始資源。而這通常是通過顯式轉(zhuǎn)換和隱式轉(zhuǎn)換來實現(xiàn)的。書中仍然是以智能指針auto_ptr和shared_ptr為例加以說明，它們提供接口get來顯式獲取原始資源指針，另外還通過重載->和.來隱式獲取原始資源。2、作者又舉了一個字體調(diào)用的例子。字體本身是一種原始資源，我們創(chuàng)建了一個類用來管理字體。因為這種原始資源比較特殊應(yīng)用場合也很多，所以存在讓資源管理類提供一個向外界開放的接口的必要性，外界通過調(diào)用這個接口從而使用字體這種原始資源。又因為最終是要使用這種原始資源的，所以必然會調(diào)用字體的類型，從而這就存在一個類型轉(zhuǎn)換的過程。同理，作者有提供了顯式和隱式轉(zhuǎn)換兩種轉(zhuǎn)換手段。顯式轉(zhuǎn)換自不必提，其實也是get，它極大地減少了資源泄露的可能性。而隱式轉(zhuǎn)換可以自動轉(zhuǎn)換為原始資源類型，但是這存在一個問題。那便是如果用戶現(xiàn)在就是想使用一個資源管理類RA的對象，那沒辦法他現(xiàn)在必須轉(zhuǎn)換為原始資源類型才能使用。而這隱含的兇兆就是如果你不經(jīng)意間刪除了RA對象，那也就意外地刪除了原始資源的對象，那么你轉(zhuǎn)換過來的也就沒了。總結(jié)一下，作者強調(diào)無論是顯示還是隱式轉(zhuǎn)換都是要視情況而定的，沒有完全的絕對。另外，RA是的職責(zé)是資源管理重在資源釋放，雖然訪問原始資源突破了類的封裝特性，但是這不是RA的首要存在意義。原則16：成對使用new和delete時要采用相同形式這個原則太簡單了。當(dāng)你new一個數(shù)組的時候你要使用delete 釋放，當(dāng)你new一個指針的時候，你要使用delete釋放。如果搭配錯了，后果都是未定義的。這其中的原理，只要你懂得new和delete是操作符，并且把內(nèi)存分配看成對象來處理，并會調(diào)用構(gòu)造和析構(gòu)函數(shù)就會明白了。原則17：以獨立語句將newed對象置入智能指針這是Effective C+中第17個原則，作者以一個示例形象地說明了這一點。有一個資源處理函數(shù)A，這個函數(shù)中接收兩個參數(shù)，它們分別是shared_ptr類型的指針和一個整形參數(shù)。但是，因為用對象來管理資源的原則，所以在這里首先有了一個資源管理類的對象，并且想把它作為A的第一個參數(shù)傳進去，而A的第二個參數(shù)用一個能返回整形參數(shù)的成員函數(shù)B作為實參傳進來。程序員為了圖省事，他直接在A的第一個參數(shù)的位置上new了一個對象C，這個對象當(dāng)然就是資源管理類的類型了，但是A接受的是智能指針類型，所以他還在此基礎(chǔ)上進行強制類型轉(zhuǎn)換到智能指針類型。這里還要介紹一個機制，那就是編譯器在產(chǎn)生函數(shù)調(diào)用碼之前，首先要對實參進行核算。那么在核算期間，上述內(nèi)容就可以分成3步：1、new 對象C；2、調(diào)用B；3、強制把C轉(zhuǎn)換成shared_ptr類型。在上述三個步驟中，1和3的順序是確定的，那就是1在先3在后。但是2卻不一定了，這是根據(jù)語言和編譯器的不同而異的，所以它們的順序可能是213、123、132。但是在123的情況下，如果調(diào)用B的過程發(fā)生了異常，導(dǎo)致程序終止，而new C返回的指針會丟失。又因為shared_ptr是用來防止資源泄露的，那么我們的目的沒有達到，new出來的C還是泄露了。所以作者在此原則中想著重強調(diào)的是，你最好不要在調(diào)用函數(shù)的過程中直接在參數(shù)列表里面進行new啊，類型轉(zhuǎn)換之類的操作，一旦發(fā)生資源泄露難以察覺，所以你最好把這些都放在函數(shù)調(diào)用之前的單獨語句里面。原則18：讓接口容易被正確使用，不易被誤用這是Effective C+中的第18條原則。1、作者在本原則中舉了一個函數(shù)接口的例子，在一般的情況下，用戶可能錯誤地輸入了參數(shù)，而導(dǎo)致程序運行不正確。針對這種情況作者推薦采用導(dǎo)入新類型來解決此問題。而這些類型，你可以使用結(jié)構(gòu)體、枚舉類型和帶有特定返回值的成員函數(shù)等來實現(xiàn)。而帶有特定返回值的成員函數(shù)一般來講是以函數(shù)體帶對象。2、再有就是，作為接口設(shè)計者，你要限制用戶能做什么不能做什么。比如說不讓用戶去染指資源管理的任務(wù)。3、讓你接口提供的行為與內(nèi)置類型的一般性行為一致。因為用戶總喜歡對他們熟悉的東西反復(fù)用，并且喜歡套用在新的東西上。所以這樣做不僅可以讓你的接口更快被用戶接受，還不容易犯錯。在這里作者舉了泛型算法的例子。4、讓接口對客戶提出最少的要求。許多接口總是要求用戶注意這注意那，要求一多，用戶就容易頭暈，這樣使用接口就更容易出錯。所以一定要讓接口被傻瓜式地使用。在這里作者又舉了智能指針的例子。原則19：設(shè)計class猶如設(shè)計type英文是：Treat class design as type design。這是Effective C+中第19個原則。對類的設(shè)計歸根結(jié)底可以歸結(jié)為類型的設(shè)計，因為類也是一種類型的存在。該原則是若干個原則的集合，而這些原則是設(shè)計一個類需要遵循的。這些原則具體如下：1、類對象的創(chuàng)建和銷毀如何進行；2、類對象賦值和初始化的區(qū)別是什么；3、類對象在何時進行值傳遞；4、類對象所能接受的值，不能接受哪些值，如何讓用戶容易使用，不容易犯錯；5、類對象需要考慮的繼承體系；6、類對象的類型轉(zhuǎn)換該如何實現(xiàn)。比如資源處理類的對象；7、對類對象來說那些操作符是必要的；8、什么樣的編譯器自動生成的或者已經(jīng)存在的成員函數(shù)你應(yīng)該自己重寫并取而代之；9、該類中哪些成員能提供給外部；10、哪些是新類的未聲明接口；（這個目前我不太懂）11、你是否要定義很多類型？如果是，你還不去寫個泛型類。否則，你只寫一個type就好了；12、你真的有必要定義一個新類型嗎？原則20：寧以引用傳遞代替值傳遞這是Effective C+中第20個原則。對于類對象而言，采用值傳遞是非常不明智的，因為它會涉及到COPY構(gòu)造函數(shù)和析構(gòu)函數(shù)的調(diào)用，如果你COPY的那個對象還包含了其他類的對象，那就會涉及到更多的函數(shù)調(diào)用，而且這是呈指數(shù)級增長的。而采用const&不僅極大地提高了效率而且還沒有任何構(gòu)造函數(shù)和析構(gòu)函數(shù)的調(diào)用。而之所以采用const則是由于先前的原則3.另外采用const&可以避免對象切割問題，雖然這個問題我還沒認(rèn)識到那么深刻。當(dāng)一個子類對象采用值傳遞方式被調(diào)用，但是被調(diào)用時的類型要求是父類類型時，那么這時父類的COPY構(gòu)造函數(shù)會被調(diào)用，不要以為這種情況不能發(fā)生，記住這正是多態(tài)的體現(xiàn)，而父類類型不過是個接口。這樣做的話，該對象本身的子類特性就會被無視。引用的底層是用指針來實現(xiàn)的，所以你會發(fā)現(xiàn)引用和指針的行為有些相仿。所以對于內(nèi)置類型，如果你以值傳遞的話效率會高些，比如說VS中指針占4個字節(jié)，而一個char占1個字節(jié)。另外對于STL迭代器和函數(shù)，都被設(shè)計為采用以值傳遞，這是合理的，為什么呢，答案在原則1。但是不能因為對象小就采用值傳遞，這是因為一方面對象雖小但牽連廣泛，它所涉及的COPY構(gòu)造函數(shù)和析構(gòu)函數(shù)也不可小覷。另一方面，小對象也不排除將來因為需求的改變而變大的傾向。原則21：必須返回對象時，別妄想返回其引用Effective C+中第21個原則，因為引用是要指向某已存在的對象的，但如果該對象某一瞬間突然消失了，這個引用被架空了，那就出錯了。為了證實這一點作者舉了一個有理數(shù)相乘的例子。有這個一個有理數(shù)類，其中有一個有理數(shù)相乘的成員函數(shù)，該成員函數(shù)返回該有理數(shù)類的對象。在此例中該對象是一個本地對象，什么叫本地對象呢？就是一個普通的，局部的對象，它隨著作用域的結(jié)束而被自動銷毀。因為具備這一性質(zhì)，一旦你把這個函數(shù)的返回值賦給某一變量，然后該函數(shù)使命完成被自動銷毀，那么它所返回的對象也就被自動銷毀了，那么被賦值的變量的行為就未定義了。然后作者又舉了動態(tài)分配對象的例子。因為是new一個對象出來，所以它肯定是要調(diào)用構(gòu)造函數(shù)進行初始化工作的，但是你往往找不到一個合理的時機進行析構(gòu)工作，從而導(dǎo)致資源泄露。因為上述兩個例子都是因為為本地對象調(diào)用構(gòu)造函數(shù)而導(dǎo)致的，那么如果把本地變量寫成static的不就避免了構(gòu)造函數(shù)和析構(gòu)函數(shù)的問題了么。作者的回答是no。因為static對象是靜態(tài)分配，它在內(nèi)存中的位置是固定的，這樣多個操作對static對象進行修改，static對象最后的內(nèi)容是最后修改的那個內(nèi)容，基于此種性質(zhì)。如果你的業(yè)務(wù)邏輯是多個對象之間才存在的，那么這樣做的后果肯定不是你想要的。最后作者給出了自己的建議你既然要返回一個對象，那就直接返回一個對象。原則22：將成員變量聲明為private這是Effective C+中第22個原則，原話是Declare data members private，即把數(shù)據(jù)成員稱名為私有的訪問權(quán)限。為什么要這樣做？先說public，public是提供用戶的接口，它根本不具備封裝特性。從實際來看，被聲明為public的都是成員函數(shù)，用戶通過操作成員函數(shù)來操作類內(nèi)的成員，而至于說這個接口的內(nèi)部細(xì)節(jié)對于用戶來說是不可見的，其中一個典型的例子就是getter和setter的運用。再有就是通過把public成員函數(shù)作為接口提供給用戶，那么這個接口的實現(xiàn)會有若干種可能以應(yīng)對不同的需求。還是因為它是接口，是給用戶使用的，所以它不能變來變?nèi)サ?，否則你叫用戶怎么用。所以一旦某個成員函數(shù)被聲明為public的，那么一般情況下它就不能再有任何變化了，當(dāng)然這個變化是從用戶的角度來看。從而推出越是廣泛使用的類，public成員聲明就越不能改變。在這里有個普遍的準(zhǔn)則，那就是封裝的越好，改變成員時所破壞的代碼量就越少。protected并不比public封裝性更好，因為你改變public只是改變用戶代碼，而你改變protected則可能導(dǎo)致所有子類的代碼的破壞，它倆的代碼破壞量都不可估量，后者更甚。所以成員一旦聲明為protected和public那就意味著它們應(yīng)該是永遠(yuǎn)不變的。所以從封裝的角度講只有兩中訪問權(quán)限可言，那就是private封裝和其他不封裝。原則23：寧以非member、非friend替換member函數(shù)這是Effective C+中第23條原則的內(nèi)容，我感到很奇怪，成員函數(shù)調(diào)用本類的成員怎么了？難道這還不夠封裝嗎？看下面的解釋吧。類中可能存在一系列函數(shù)用來處理一系列操作，而這一系列函數(shù)可以放在類中某一成員函數(shù)中一起執(zhí)行，但是也可以放在一個非成員函數(shù)中一起執(zhí)行。那么從封裝性上來講哪一個好呢？答案是非成員函數(shù)，這是因為成員函數(shù)還可以訪問類中的私有成員，但是非成員函數(shù)連私有成員都訪問不了，所以非成員函數(shù)的封裝性更好。要知道越多東西被封裝，就會有更大的余地在不為人知的情況下更改被封裝的數(shù)據(jù)，在這里友元函數(shù)和成員函數(shù)一樣，所以本原則推崇的是非友元函數(shù)和非成員函數(shù)。這對于那些純面向?qū)ο笳Z言，像JAVA，而言很不幸，因為它們沒有獨立的函數(shù)存在。所以在這種情況下可以考慮寫一個工具類，在此類中添加函數(shù)，這樣這些函數(shù)就不是成員函數(shù)了。而C+的做法是把這些獨立的函數(shù)和被操作的類放在同一命名空間下。本原則這樣做的另一個原因是出于可擴展原則。因為完成某一特定功能可能需要一系列的函數(shù)，但是你可能需要完成很多功能，而這些功能都屬于同一個工程。這個時候你可以為這個工程明明一個名字空間，然后把每個功能寫在一個獨立的頭文件里面，因為它們共同隸屬于同一個命名空間，所以在某個頭文件中你就可以把操作那一系列成員函數(shù)的非成員非友元函數(shù)也寫在同一頭文件同一命名空間下。這樣做既降低了編譯相依性也提高程序擴展性。原則24：若所有參數(shù)皆需要類型轉(zhuǎn)換，請為此采用非member函數(shù)這是Effective C+中第24個原則，即非成員函數(shù)能夠完美解決題目中所敘述的情景。作者以一個有理數(shù)類的例子來詮釋本原則所述內(nèi)容。這個例子大致是這樣的，這個有理數(shù)類有一個帶有默認(rèn)值參數(shù)的構(gòu)造函數(shù)，并且也有一個重載的乘法操作符，并且這個重載操作符函數(shù)只接受一個有理數(shù)類的對象?，F(xiàn)在在它參數(shù)的位置上放上一個整數(shù)，因為構(gòu)造函數(shù)并非顯示，所以它允許將這個整數(shù)隱式轉(zhuǎn)換成該類的類型而參與運算。但是奇怪的現(xiàn)象來了，因為這個重載操作符是單目操作符，這時出現(xiàn)了一個賦值語句，這個*就是這個單目操作符，oneHalf是一個有理數(shù)類對象，2是整數(shù)，2可以被隱式轉(zhuǎn)換成有理數(shù)類型。但是下面這個表達式從邏輯上將實現(xiàn)的功能是一樣的，但是它確報錯，這是為啥呢？那是因為這個*的函數(shù)原型如下所示：因為2并不在參數(shù)列表中，根本不存在類型轉(zhuǎn)換，而又因為它要求的是兩個有理數(shù)類型參與運算，因此2壓根不符合類型要求，所以會報錯。而這就是所謂的只有被列于參數(shù)列表內(nèi)，這個參數(shù)才是隱式轉(zhuǎn)換的合格參與者。那這里你一定會冒出一個疑問，既然參數(shù)列表里面只有一個參數(shù)，那你就改寫一下這個重載操作符的函數(shù)唄，這樣兩個參數(shù)不就都能進行隱式轉(zhuǎn)換了嗎？嗯，這個想法是好的，不過類中的*重載操作符不支持兩個參數(shù)的形式，請看下面的圖示：但是非成員函數(shù)的*重載操作符函數(shù)卻能支持兩個參數(shù)的形式，這樣兩個參數(shù)都能進行隱式轉(zhuǎn)換了。那么為什么不把非成員函數(shù)設(shè)成有原函數(shù)呢？那是因為有原函數(shù)的存在極大地破壞了封裝特性，不符合面向?qū)ο蟮乃枷耄瑏y用的話會帶來很大麻煩，所以能不用就不用。原則25：考慮寫出一個不拋出異常的swap函數(shù)Effective C+中第25個原則，頗為復(fù)雜，作者用了很長的篇幅來講這個原則，我在理解這個原則上也花了不少功夫。我還是先敘述一下這個作者所述的例子吧。話說在STL有這么一個泛型算法名叫SWAP，其功能如其名，就是用來交換，它能交換兩個類型的對象，那更不用說內(nèi)置類型，因為內(nèi)置類型也可以說是某種類型的對象吧，只要被交換類型支持復(fù)制COPY操作就行。但是這個泛型算法的思路還是讓一個臨時變量tmp先接收一個對象a，然后把另一個對象b賦給這個對象a，之后再把這個臨時變量tmp的值再賦給a。思路很簡單，也很正常，然后在某些情況下這種做法帶來的卻是效率的低下。作者舉了一個常見的場景，那就是用指針指向一個對象的時候（pimpl，pointer to implementaion）這種做法具體就是一個類A用來操作指針，這個指針指向類B，另一個類B中的內(nèi)容才是實質(zhì)的內(nèi)容。指針很小，但是對象很龐大，這個時候你再用復(fù)制的方法來交換那花費的時間就不是一般兩般的長了，占用的臨時空間也非常大。如果用泛型算法SWAP來交換兩個A對象的話，因為A對象中有指針已經(jīng)指向了B的對象，再加上SWAP中間的臨時變量tmp，那么SWAP不僅僅賦值了3個A對象，而且還復(fù)制了3個B對象，而后者并不是我們想要的，其效率之低下由此可見一斑。而我們想要的只是進行到A的指針就可以了。那這個時候該怎么辦呢？那我們就私人定制一個A類專屬的SWAP好了，這就是所謂的SWAP針對A類的特化。具體的做法就是弄一個全特化的SWAP版本，用它來交換給定對象中所包含的指針，然而這一版本并不能成功因為這個指針是私有的。解決這個問題的辦法你可以考慮使用友元函數(shù)，但是基于友元函數(shù)對于封裝性的破壞，我們能不用就不用。所以最好的做法就是聲明一個A類的公有成員函數(shù)SWAP，然后在這個公有成員的SWAP函數(shù)里面調(diào)用泛型算法只用來交換指針，這樣它就能訪問A的私有成員指針了。同時，在同一命名空間下再聲明一個非成員函數(shù)的SWAP，它的參數(shù)被特化為A類型，這樣它直接調(diào)用實參對象，也就是A類型對象的公有接口SWAP就可以完成交換了。而這種做法也恰恰符合了STL的風(fēng)格。不過，上面這種做法并不適合泛型函數(shù)級別上進行偏特化，因為C+只允許對泛型類級別上進行。那一般而言應(yīng)對這種情況的做法就是寫一個重載函數(shù)，這個重載函數(shù)只有參數(shù)是特化的。不過，不要往std里面添加重載的泛型函數(shù)，也可以說成是你不要往std里面添加新東西，因為這些都是標(biāo)準(zhǔn)。所以，你還是自己弄個命名空間然后把這些放到里面去。有的時候純粹是為了方便，你希望你的特化SWAP被最大化使用，你還是應(yīng)該在你自定義的命名空間內(nèi)std的特化版本SWAP和本類的專版，這樣編譯器就會根據(jù)實參的具體類型自動選擇最合適的版本了。另外，SWAP作為成員函數(shù)決不能拋出異常，因為它是幫助類提供一個異常安全性的保障。不過這一點不適用于非成員函數(shù)的SWAP，因為它是基于拷貝構(gòu)造函數(shù)和拷貝賦值操作符函數(shù)，而這兩者是可能拋出異常的。一個規(guī)律就是你的SWAP效率越高，它的異常安全性越好，一個特例就是當(dāng)SWAP操作內(nèi)置類型時SWAP根本不可能拋出異常。什么是全特化？就是凡事涉及到泛型類型的地方都用特定類型代替之。什么是偏特化？就是非全特化。通過上述內(nèi)容作者想表達3個觀點：1、當(dāng)那個泛型SWAP效率實在低下時，你自己寫一個，但是要確保不拋出異常；2、如果你的SWAP是成員函數(shù)，那你一定要用一個非成員函數(shù)來調(diào)用這個成員SWAP，并且特化一個std:SWAP；3、不要往std里添加全新的東西。原則26：盡可能延后變量定義式的出現(xiàn)時間Effective C+中第26條原則，總的來說就是這個變量你定義早了，你很難一眼看到這個變量在哪用了；如果你定義早了，這個變量你可能壓根沒用到過，那你就是白白浪費了空間。如果你定義的變量是個對象，那你還要花費構(gòu)造函數(shù)和析構(gòu)函數(shù)的代價。如果在你定義變量之后程序由于異常而中斷了，這個變量你根本沒用著，那你賠的更多了。再有就是在你定義對象時最好直接給它賦值，因為如果你不這樣做，它是首先調(diào)用默認(rèn)構(gòu)造函數(shù)，然后再調(diào)用拷貝賦值函數(shù)，但是如果你直接拷貝那就不會調(diào)用默認(rèn)構(gòu)造函數(shù)了，所以這在效率上是一個提升。本原則還講到一個用于循環(huán)的變量是定義在循環(huán)內(nèi)還是外？如果在內(nèi)，那么你每次都要要調(diào)用拷貝構(gòu)造函數(shù)和析構(gòu)函數(shù)，你循環(huán)多少次就調(diào)用多少次。如果在外，你只調(diào)用一次構(gòu)造和析構(gòu)函數(shù)，循環(huán)多少次就調(diào)用多少次拷貝賦值操作函數(shù)多少次。作者說這是有條件的，這取決于拷貝構(gòu)造函數(shù)的代價，如果一次拷貝的代價小于一次構(gòu)造函數(shù)+析構(gòu)函數(shù)的代價，那么在外比較好，尤其是在循環(huán)次數(shù)比較多的情況下，反之在內(nèi)比較好。不過，從代碼的可讀性和可維護性方面來講，作者比較傾向于在內(nèi)的做法。原則27：盡量少做類型轉(zhuǎn)換動作這是Effective C+中第27個原則，作者花了很長的篇幅來介紹這一原則?？偠灾痪湓挘驗轭愋娃D(zhuǎn)換會導(dǎo)致破壞類型系統(tǒng)，從而帶來明顯的和不明顯麻煩，而且這是C+獨有的特性。C+提供了四種新型的類型轉(zhuǎn)換，就是下面這四種：const_cast是把const類型轉(zhuǎn)換成非const類型；dynamic_cast是類體系中進行轉(zhuǎn)換；reinterpret_cast是一個很強大的類型轉(zhuǎn)換，最常用的是指針轉(zhuǎn)換為指針，而且是兩個毫不相關(guān)的指針之間的轉(zhuǎn)換，它傳遞的是比特位。換句話說這些比特位是不變的，但是它能按照另一種方式來解釋它。static_cast就是平常的類型轉(zhuǎn)換，用的最廣泛。須知，在C+中，類型轉(zhuǎn)換往往能夠令編譯器編譯出運行時代碼，可想而知，這個代碼并不是你寫的。在這里作者舉了一個多態(tài)的例子，當(dāng)你用父類的指針指向子類的對象時，父類的指針指向的地址和子類對象所在的地址并不是一個，它倆之間有時候是有個偏移量的。作者又舉了一個例子。現(xiàn)有一父類和其子類，兩類有兩個同名的虛函數(shù)，現(xiàn)要求子類虛函數(shù)中首先調(diào)用父類虛函數(shù)，這是子類虛函數(shù)的代碼是這樣子的。通過子類的this指針強制類型轉(zhuǎn)換成父類類型，然后調(diào)用同名函數(shù)。但是次轉(zhuǎn)換的過程并不是你所想象的那樣簡單，這個強制類型轉(zhuǎn)換會創(chuàng)造出一個被轉(zhuǎn)型對象的副本，它是在這個副本身上執(zhí)行父類的同名函數(shù)，而在該對象身上執(zhí)行本類專屬的同名函數(shù)，兩者本應(yīng)作用于同一個對象而實際上卻沒有。而解決這個問題的辦法就是不用強制類型轉(zhuǎn)換，你該用父類的成員函數(shù)就用就行了。而dynamic_cast這個轉(zhuǎn)換你最好不要用，因為它是動態(tài)轉(zhuǎn)換，它會在整個類層次上進行尋找，而且每轉(zhuǎn)換一次就尋找一次，并且它是按照類名進行字符串匹配的。通常你使用dynamic_cast進行強制類型轉(zhuǎn)換的情景是用一個父類的指針指向子類對象，這種情況你應(yīng)該使用的是子類類型的只能指針，作者使用的是一個裝有智能指針的vector。如果子類很多，并且你非要用父類類型的話，那你可以在父類中提供一個同名空虛函數(shù)，并在各個子類中去實現(xiàn)它，然后你再用vector去容納裝有父類類型的智能指針，然后去操作。為啥要使用vector呢？因為它是類型安全容器。在這里一定要記住不要在程序中多次使用dynamic_cast做沒有必要的類型轉(zhuǎn)換，因為這樣做不僅代碼多，而且運行慢，因為dynamic_cast需要查找嘛。最后作者衷心地告訴大家盡量不要使用強制類型轉(zhuǎn)換，尤其是除static_cast之外的另外三種；強制類型轉(zhuǎn)換如果必要，那也要把它包裹在一個函數(shù)里面，不要讓用戶接觸到；推薦使用C+強制類型轉(zhuǎn)換，它不僅容易分辨，而且各司其職。原則28：避免返回handles指向?qū)ο蟮膬?nèi)部成分在這里首先要明確啥是handles，這里所說的handles就是通常所說的引用、指針或者迭代器等具有指代性質(zhì)的標(biāo)簽。那么題目所說的意思就是你返回的那個handles不要涉及對象內(nèi)部的東西。在敘述此原則的過程中作者舉了一個矩形Rectangular的例子，說舉行的四個頂點存儲在一個結(jié)構(gòu)體中，Rectangular提供了兩個公有接口upperleft和lowerright它們返回的是該矩形左上角和右下角的頂點的坐標(biāo)結(jié)構(gòu)體，并且是以引用的形式返回的。因為用戶只需知道這些頂點的坐標(biāo)而無需對這些頂點進行操作，因此這倆接口都是常函數(shù)。但是矛盾出現(xiàn)了，常函數(shù)的作用是不允許用戶去修改，但是這兩個常函數(shù)卻返回了Rectangular的私有成員。另外常函數(shù)只是說在常函數(shù)體內(nèi)不進行更改數(shù)據(jù)成員的操作，它返回的東西并不一定是常量。既然如此用戶就很有可能通過這倆接口去改變Rectangular類原本私有成員，這是極其不符合該程序的初衷和封裝性原則的。所以作者在這里說“成員變量的封裝性最多等于其返回引用的訪問級別”是很有道理的。作者還說非公有的成員函數(shù)也是內(nèi)部數(shù)據(jù)，這不是廢話嘛，我早就知道啊。作者想表達是啥呢，就是從訪問級別上來講，不要讓那些訪問級別高的成員函數(shù)返回指向訪問級別低的成員函數(shù)的handles，不過在我看來，具體來講就是不要讓公有接口返回任何非公有的成員的handles。那么這原則中所提及的問題是怎么解決的呢？正如我所說的，常函數(shù)只是在函數(shù)體內(nèi)不能對數(shù)據(jù)成員更改，但是它返回的東西并不一定不能被更改，所以呢，那么就把返回值也設(shè)成const就OK了。盡管如此呢還是有個問題存在，那就是函數(shù)雖然返回了const成員不能被更改，但是作為右值的語句結(jié)束以后，它的生命期就結(jié)束了，那右值的東西被析構(gòu)掉左值不就成了空吊子。所以返回只想對象內(nèi)部成分的handles總是危險的，作者最后總結(jié)道：能不用handles只想對象內(nèi)部就不用，這樣可以增加封裝性，最好在const函數(shù)的返回類型上也加個const，也盡量避免空吊的出現(xiàn)。原則29：為“異常安全”而努力是值得的我怎么發(fā)現(xiàn)最近記錄的這幾條原則的敘述內(nèi)容都很冗長無法一眼兩眼就能看懂。作者首先從一個類似于從MFC取材的例子，就是更換背景色的一個功能，并且它是在多線程環(huán)境下工作的。這個功能的具體實現(xiàn)首先加上互斥鎖，刪除舊背景，記錄圖像更改次數(shù)，生成最新的背景圖片，去掉互斥鎖。然而，這種步驟并不符合異常安全性。因為作者說這種實現(xiàn)不符合異常安全性，而所謂的異常安全性，具體來講包括2個方面，它們是：1、不泄露任何資源：上例很難做到，因為咋生成新的背景圖片這一步，如果出現(xiàn)異常，程序就不會繼續(xù)往下執(zhí)行，那么互斥鎖就永遠(yuǎn)不會解鎖，那么占用的資源就會被釋放，那么就會造成資源泄露。怎樣做到不泄露呢？條款14說過就是用資源管理類。這一點有點區(qū)別，在不使用資源管理類時使用互斥鎖下圖這樣的：而使用資源管理類機制之后是如下的情形：Ml是Lock的一個對象，這樣它有自己的構(gòu)造函數(shù)和析構(gòu)函數(shù)，這就避免了資源泄露，而且這不僅使程序較短而且還免去了寫unlock，降低了程序的復(fù)雜性也就有效地降低了出錯的可能性。