EffectiveC中文版第三版高清PDF歸納

1、EffectiveC+閱讀筆記EffectiveC+閱讀筆記1原則3:盡可能使用const5原則5:了解C+默默編寫并調(diào)用哪些函數(shù)7原則6:若不想使用編譯器自動(dòng)生成的函數(shù)，就應(yīng)該明確拒絕9原則7:為多態(tài)基類聲明virtual析構(gòu)函數(shù).12原則8:別讓異常逃離析構(gòu)函數(shù)1.6原則9:絕不在構(gòu)造和析構(gòu)過程中調(diào)用virtual函數(shù)17原貝U10:令operator=返回一個(gè)referenceto*this20原則11:在operator=中處理自我賦值”20原則12:復(fù)制對(duì)象時(shí)勿忘其每一個(gè)成分22原則13:以對(duì)象管理資源23原則14:在資源管理類中小心COPYING行為25原則15:在資源管理類中提供

2、對(duì)原始資源的訪問26原則16:成對(duì)使用new和delete時(shí)要采用相同形式28原則17:以獨(dú)立語句將newed對(duì)象置入智能指針29原則18:讓接口容易被正確使用，不易被誤用30原則19:設(shè)計(jì)class猶如設(shè)計(jì)type31原則20:寧以引用傳遞代替值傳遞32原則21:必須返回對(duì)象時(shí)，別妄想返回其引用33原則22:將成員變量聲明為private34原則23:寧以非member、非friend替換member函數(shù)36原則24:若所有參數(shù)皆需要類型轉(zhuǎn)換，請(qǐng)為此采用非member函數(shù)37原則25:考慮寫出一個(gè)不拋出異常的swap函數(shù)39原則26:盡可能延后變量定義式的出現(xiàn)時(shí)間42原則27:盡量少做類型轉(zhuǎn)

3、換動(dòng)作43原則28:避免返回handles指向?qū)ο蟮膬?nèi)部成分46原則29:為“異常安全”而努力是值得的48原則30:透徹了解inline（內(nèi)聯(lián)）的里里外外.52原則31:將文件間的變異依存關(guān)系降至最低55原則32:確定你的public繼承塑造出了IS-A關(guān)系58條款33:避免屏蔽繼承而來的名字59原則34:區(qū)分接口繼承和實(shí)現(xiàn)繼承60原則35:考慮virtual函數(shù)以外的其他選擇63原則36:決不能重新定義繼承而來的非virtual函數(shù)67原則37:絕不重新定義繼承而來的缺省參數(shù)值69原則38:通過復(fù)合塑造出HAS-A關(guān)系或者根據(jù)某物實(shí)現(xiàn)出來71原則39:明知而審慎地使用PRIVATE繼承72原

4、則40:明智而審慎地使用多重繼承78原則41:了解隱式接口和編譯期多態(tài)81原則42：了解typename的雙重意義82原則43:學(xué)習(xí)處理模版化基類內(nèi)的名稱84原則44:將與參數(shù)無關(guān)的代碼抽離templates86原則45:運(yùn)用成員函數(shù)模版接受所有兼容類型88原則46:需要類型轉(zhuǎn)換時(shí)請(qǐng)為模版定義非成員函數(shù)90原則47:請(qǐng)使用traitsclasses表現(xiàn)類型信息.92原貝U48:認(rèn)識(shí)template元編程96原貝U49:了解new-handler的行為98原則50:了解new和delete的合理替換時(shí)機(jī)102條款51:編寫new和delete時(shí)需固守常規(guī)104原貝U52：寫了placementn

5、ew也要寫placementdelete106原則54:不要忽視編譯器的警告108原則54:讓自己熟悉包括TR1在內(nèi)的標(biāo)準(zhǔn)程序庫109原則55:讓自己熟悉Boost110本來是寫在百度空間的，但是不知道咋回事百度博客中圖片看不到了，所以百度博客的不穩(wěn)定性可見一斑。于是我決定將我的領(lǐng)會(huì)和感受寫在自己的云盤里面。雖好也弄個(gè)目錄啥的，最后再整車成PDF格式的。這個(gè)標(biāo)準(zhǔn)我就參考我研究生期間論文的格式吧。原貝U3:盡可能使用constEffectiveC+里面第3條原則是盡量使用const。其原因是防止無意中更改而本來不應(yīng)該更改的變量。本條款也提到const成員函數(shù)的重要性，原因之一就是只有const函

6、數(shù)才能用來操縱const對(duì)象。而所謂const對(duì)象就像下圖所示的這樣：constTextBlockctbWorld);有的時(shí)候會(huì)遇到在const函數(shù)中更改非const成員變量的情況，這個(gè)時(shí)候就要用到mutable關(guān)鍵字了。如果一個(gè)成員變量被mutable修飾，那么它在const函數(shù)中仍然可以被修改，但是前提是該成員變量是非const成員。還有一種情況就是為了防止代碼重復(fù)，比如兩個(gè)函數(shù)實(shí)現(xiàn)了同樣的功能只是類型不同而已，這樣就會(huì)導(dǎo)致兩段幾乎相同的代碼段，這無疑會(huì)增加編譯時(shí)間、維護(hù)和代碼膨脹等風(fēng)險(xiǎn)。在本原則的有關(guān)敘述中，作者采用了強(qiáng)制類型轉(zhuǎn)換來解決之，雖然作者本身在大多數(shù)情況下并不提倡做法。為了給用

7、戶一個(gè)一目了然的接口，一看就知道那些成員函數(shù)可以操縱const對(duì)象而哪些不能，作者建議在類中明確將那些不改變對(duì)象的成員函數(shù)聲明為const函數(shù)，雖然const成員函數(shù)可以使用非const成員變量，但是遵守這一原則會(huì)給客戶帶來極大的便利。因?yàn)閏onst成員函數(shù)不更改對(duì)象，這就防止了由于誤操作而帶來的問題，因?yàn)樽詈糜梅莄onst成員函數(shù)去調(diào)用const的實(shí)現(xiàn)，說白了就是直接return這個(gè)const成員函數(shù)，只不過需要對(duì)作為這個(gè)return的表達(dá)式的const成員函數(shù)進(jìn)行一下強(qiáng)制類型轉(zhuǎn)換使其成為非const型的。所以，在這里不得不提一下純粹的C+的強(qiáng)制類型轉(zhuǎn)換。關(guān)鍵在static_cast(val

8、ue)是純粹的C+強(qiáng)制類型轉(zhuǎn)換的關(guān)鍵詞和用法，它的使用頻率是最高的。-1voidmain()4|int13;coutstati-c_cast(a)endl;7cin,get();Sconst_cast(value)是用來消除const屬性時(shí)用的。不過它不能用于基本類型。reinterpret_cast(value)它用于無關(guān)類型之間的轉(zhuǎn)換。dynamic_cast(value)用于父子類指針之間的轉(zhuǎn)換。在C+語言中只有這4中強(qiáng)制類型轉(zhuǎn)換。原則5:了解C+默默編寫并調(diào)用哪些函數(shù)這一篇博客是EffectiveC+中第5個(gè)條款。但現(xiàn)在感覺我還沒太理解它到底說了什么，所以想寫寫博客，萬一寫著寫著就明白

9、了呢。首先在這里敘述一個(gè)機(jī)制，那就是空類，在默認(rèn)的情況下，編譯器會(huì)給它自動(dòng)生成默認(rèn)的構(gòu)造函數(shù)、拷貝構(gòu)造函數(shù)、拷貝賦值操作符=和析構(gòu)函數(shù)。并且他們都是public的和inline的-classEmpty11I?!13；它與下面這個(gè)類是一樣的。-classEmptpublic:Empty0；Empty(constEmptySrhs):mpty()：Emptvfioperator=(constEmptvfirhs);；至于這些成員函數(shù)和操作符是干啥用的，我在前邊的博文中闡述過了。其中，默認(rèn)的構(gòu)造函數(shù)負(fù)責(zé)調(diào)用父類和非static的構(gòu)造函數(shù)和析構(gòu)函數(shù)。如上圖可見編譯器自動(dòng)生成的

10、析構(gòu)函數(shù)是非virtual的，如果父類中本身存在virtual的析構(gòu)函數(shù)，編譯器就不會(huì)自動(dòng)產(chǎn)生非virtual的析構(gòu)函數(shù)了。而默認(rèn)的copy構(gòu)造函數(shù)和copy賦值操作符只是copy非static成員到目標(biāo)對(duì)象。不過，如果你手動(dòng)寫了它們中的一些，編譯器就只會(huì)自動(dòng)生成你沒寫的。比如你只寫了構(gòu)造函數(shù)，那么其他的東西編譯器負(fù)責(zé)給你自動(dòng)生成。至于說copy構(gòu)造函數(shù)和copy賦值操作符的用法我以前的博文有提到過。而copy構(gòu)造函數(shù)總是層層調(diào)用底層的copy構(gòu)造函數(shù)來進(jìn)行賦值，比如說copy構(gòu)造函數(shù)要copy一個(gè)string類型的變量，那么它就會(huì)調(diào)用string的copy構(gòu)造函數(shù)，實(shí)在沒辦法了，它再自己進(jìn)行

11、賦值操作。其實(shí)本原則著重討論的是在什么情況下編譯器不會(huì)自動(dòng)生成這些東東。對(duì)于默認(rèn)的構(gòu)造函數(shù)而言，當(dāng)你手動(dòng)寫了一個(gè)構(gòu)造函數(shù)的話，編譯器就不會(huì)再費(fèi)那個(gè)勁了。而對(duì)于copy賦值操作符呢也是有自動(dòng)生成條件的，那就是這個(gè)copy賦值操作符確實(shí)有存在的意義，并且它能在使用場(chǎng)合能正確工作，否則除非你自己手動(dòng)寫一個(gè)，要不然編譯器是不會(huì)給你生成這些東東的。而在書中作者舉了2個(gè)例子1個(gè)是引用，另一個(gè)是const常量，這兩者所指的對(duì)象都是不能更改的，那你非要給它們賦值，那肯定會(huì)導(dǎo)致copy賦值操作符的失敗。書中還舉個(gè)1個(gè)例子，一般情況下父類中如果有copy賦值操作符，在子類中編譯器是不會(huì)再給自動(dòng)生成copy賦值操作

12、符，直接使用父類的就好了，因?yàn)榫幾g器認(rèn)為子類的copy賦值操作符是要能夠處理父類的賦值操作的。所以如果你此時(shí)把父類的copy賦值操作符設(shè)置為private的，那么你就沒有copy賦值操作符可用了，除非你自己在子類中寫一個(gè)。101112131415161718192021原則6:若不想使用編譯器自動(dòng)生成的函數(shù)，就應(yīng)該明確拒絕這是EffectiveC+中第6個(gè)原則，在某些情況下你不想讓某些類的對(duì)象被拷貝，那么在這種情況下即使你不寫copy構(gòu)造函數(shù)和copy賦值操作符編譯器也會(huì)為你生成，那么你不得不自己寫它們倆。而你又不希望別人調(diào)用它們，所以這時(shí)你要將它們聲明為private類型。一且你寫了，編譯器

13、就不會(huì)自動(dòng)調(diào)用父類的copy構(gòu)造函數(shù)和copy賦值操作符。即使這樣本類內(nèi)部成員函數(shù)和友元函數(shù)還是可以調(diào)用它們，該如何是好？辦法就是你只聲明這些函數(shù)而不去實(shí)現(xiàn)，沒有實(shí)現(xiàn)就自然沒有功能了，而既然實(shí)際上沒用，你甚至連形參都可以省略，只在形參列表中寫個(gè)形參類型即可，就像下圖類的定義所示的這樣:-classEmptv(public;Empty(string&stra*intaa)；voidEmptyFnnction();Empty(constEmptyA)構(gòu)造函數(shù)口筆/Emptyftoperator=(constEniptyfi:)copy賦值操作符。public:stringstr;inta;)：其中

14、的幾個(gè)函數(shù)實(shí)現(xiàn)如下所示:3 I-voidEmpty：IEmptyFunction()4 151cout-Ca(0)9|LOlstr=stra;111a=aa：12|)從上圖可見，copy構(gòu)造函數(shù)和copy賦值操作符都沒有實(shí)現(xiàn)。在主程序中是如下調(diào)用的：:二-intmain()4|5Emptya(總tatgtring)(”哇啥哈,1。1);cauta.&trendl;Emptyb(a);CQutb.&trfendL;cin.get():0return0;1運(yùn)行結(jié)果如下所示：)：生或,|之|AA|一動(dòng)生成：項(xiàng)目：ConsoleApplicatiohI.酉d匿：DebugMin32erroiLHKtO

15、19.無法解析的外言符號(hào)putbLic_th.iscallEinpty.Bripty(classEmptyccnsl&)(?OEmpLy0E!QAE&ABVO0SZ)?該符g在由基soleApplicatianlVDebugConsoleApplicationl.esce:fatalerror1M11S0:1個(gè)無志解析的外部命令成：成功。個(gè)，失敗1個(gè)，最新。個(gè)，跳過口個(gè)=出現(xiàn)了錯(cuò)誤提示，說copy構(gòu)造函數(shù)無法解析。現(xiàn)在我把copy構(gòu)造函數(shù)和copy賦值操作符都注釋掉。dclassEmptv(public:Empty(string:stra,infaa);voidEmptyFunction();

16、二Empty(constEmptyR);*匕0口丫構(gòu)造函數(shù)：*，Empty&operator=(constEmpt&);賦值操作符口*public：stringstr;inta;)：在運(yùn)行得如下結(jié)果:哇哈哈你就要自己手寫而本思想只在闡述如果你不想讓編譯器為你自動(dòng)生成函數(shù),原則7:為多態(tài)基類聲明virtual析構(gòu)函數(shù)這是EffectiveC+中第7條原則，其內(nèi)容是在具有多態(tài)用途的父類中應(yīng)該使用virtual析構(gòu)函數(shù)。首先要知道啥是多態(tài)。我就好說直白的，顯得沒有深度的東西。多態(tài)的一種體現(xiàn)就是通過父類的指針指向不同的子類來實(shí)現(xiàn)不同的功能，從而達(dá)到接口重用的目的。在這種情況下用作多態(tài)的父類往往具有至少

17、一個(gè)virtual成員函數(shù)留給子類來實(shí)現(xiàn)。好了，現(xiàn)在鋪墊完畢了，來說正題，為啥要有一個(gè)virtual析構(gòu)函數(shù)呢？那是因?yàn)槿绻麤]有這樣一個(gè)virtual析構(gòu)函數(shù)的話，子類的析構(gòu)函數(shù)就不會(huì)被調(diào)用，那么對(duì)象的子類部分不會(huì)被析構(gòu)，那么就會(huì)造成資源的泄露?，F(xiàn)在來看下面的例子：2l-3classbase3l4public:base()cout/ba&e/endl;6 )base0coutbaseendl;7 ：sl9 -classderived:publicbase10 I(1public:2Iderived()cout*derivedyendl;3lderivedOcoutderivedendl;4;d

18、erived繼承了base,并且base中并沒有virtual析構(gòu)函數(shù)，那么調(diào)用過程如下所示:-inimain()(base覃a二newderivedO;deletea;cin.get();return0;運(yùn)行結(jié)果如下所示:-classbaseiz.131415161718192021/aO-Q從這個(gè)結(jié)果可以看到父類的析構(gòu)函數(shù)執(zhí)行了，說明對(duì)象的父類部分所占資源已經(jīng)被釋放，但是子類的析構(gòu)函數(shù)并未調(diào)用這說明對(duì)象中子類部分所占資源并未得到釋放。但是如果在父類中加上一個(gè)virtual析構(gòu)函數(shù)的話就不一樣了。public:base()cout/zbaseendl;virtualbase()cout*ba

19、seMendl;：、-classderived：publicbasepublic:derived()coutderivedvendl;derived()coutJderivedendl;-同樣的調(diào)用過程，運(yùn)行結(jié)果如下所示:basederivedderived這說明對(duì)象的子類部分所占資源也被釋放掉了。在這里再說點(diǎn)別的，一般來講作為要被繼承的父類的類中至少含有一個(gè)virtual的成員函數(shù)留給子類去實(shí)現(xiàn)。而如果某類中一個(gè)virtual成員函數(shù)都沒有的話，在很大程度上說明了該類不會(huì)被作為父類而存在，在這種情況下不應(yīng)該把其析構(gòu)函數(shù)設(shè)為virtual的。為啥呢？這與C+中virtual本身的實(shí)現(xiàn)機(jī)制有關(guān)，

20、因?yàn)檫@樣的類的對(duì)象必須要攜帶一個(gè)表，這個(gè)表叫vtbl,所以本來沒必要多帶這么個(gè)表，但是你非要多出一個(gè)來占個(gè)空間，這就是占個(gè)茅坑不拉屎的表現(xiàn)啊。所以不準(zhǔn)備被繼承的類是沒有必要設(shè)置virtual析構(gòu)函數(shù)的。在這里在介紹一種情況，當(dāng)你希望在virtual類中把析構(gòu)函數(shù)設(shè)為virtual的時(shí)候，應(yīng)該吧析構(gòu)函數(shù)設(shè)為純virtual函數(shù)，并且給與空的實(shí)現(xiàn)，如下圖所示:Eihas巖二：base()為啥要這樣做呢？因?yàn)槲鰳?gòu)函數(shù)調(diào)用順序是從沒有子類的子類那里的析構(gòu)函數(shù)逐層調(diào)用父類的析構(gòu)函數(shù)，所以如果這個(gè)純virtual函數(shù)沒有實(shí)現(xiàn)的話，編譯器就會(huì)報(bào)錯(cuò)。這個(gè)原則簡(jiǎn)而言之就是，只有作為多態(tài)用途的父類才有必要使用vi

21、rtual析構(gòu)函數(shù)，其他的就是畫蛇添足。另外，處于繼承機(jī)制的類對(duì)象包含了它所能涉及到的最低層次及其以上的所有層次的成分。原則8:別讓異常逃離析構(gòu)函數(shù)這是EffectiveC+的第八條原則。主要說的是程序出現(xiàn)的異常不要從析構(gòu)函數(shù)這里漏掉，也就是說析構(gòu)函數(shù)應(yīng)該承擔(dān)起攔截異常的責(zé)任才行。如果異常越過了析構(gòu)函數(shù)這一關(guān)，流竄到其他地方去，那么就會(huì)造成程序提早結(jié)束或者未知的風(fēng)險(xiǎn)，這個(gè)后果就很嚴(yán)重了。對(duì)付這種情況通常有兩種簡(jiǎn)單粗暴的手段：1、在析構(gòu)函數(shù)內(nèi)發(fā)現(xiàn)異常，立刻捕捉到并且結(jié)束整個(gè)程序；2、在析構(gòu)函數(shù)中發(fā)現(xiàn)異常，立刻捕捉到并將其扼殺，掩人耳目，繼續(xù)執(zhí)行程序。其中第一種手段比第二種手段要好，這是為啥呢？因

22、為方法1直接結(jié)束程序，其結(jié)果是可預(yù)料的，不會(huì)造成太大破壞。而方法2你這個(gè)異常是終止了，但是程序中其他部分與這個(gè)功能相關(guān)的勢(shì)必會(huì)造成影響，也許還會(huì)因此帶來其他異常的連鎖反應(yīng)，這個(gè)就不好辦了。不過以上這兩種方法都沒能去正面處理出現(xiàn)的異常，所以這兩種方法都不提倡。書中給出的解決方案是，再創(chuàng)建一個(gè)類用來處理異常，在這個(gè)類中有一個(gè)成員函數(shù)專門用來處理原來的類中的異常。而這個(gè)成員函數(shù)是調(diào)用原類中的異常處理來完成的，這實(shí)際上就是變相的讓原類自己處理異常，這是第一道關(guān)卡。然后異常處理類的析構(gòu)函數(shù)中也有一份處理異常的代碼，這部分是異常處理類自己的，這是第二道關(guān)卡。這個(gè)就是雙保險(xiǎn)，如果說在第二道關(guān)卡仍然不能有效處

23、理異常，那沒辦法了，只能強(qiáng)行關(guān)閉程序了。再總結(jié)一下本原則就是無論如何也不能讓異常突破析構(gòu)函數(shù)這一關(guān)。原貝U9:絕不在構(gòu)造和析構(gòu)過程中調(diào)用virtual函數(shù)這是EffectiveC+中的第9條原則。簡(jiǎn)單的來說，如果你在父類的構(gòu)造函數(shù)中調(diào)用了虛擬函數(shù)，那么子類的成員就會(huì)始終處于未初始化的狀態(tài)，這樣對(duì)象的子類成分就會(huì)出現(xiàn)不可預(yù)知的行為，這是非常危險(xiǎn)的。那么這是為什么呢？在繼承體系當(dāng)中，你聲明了一個(gè)子類對(duì)象，那么這個(gè)子類對(duì)象其實(shí)是很復(fù)雜的，它包含了子類所有父類的成分。而這些成分是要一層一層的進(jìn)行初始化的，具順序是按照類的繼承層次從上而下進(jìn)行的，即從最遠(yuǎn)的那個(gè)父類到最近的那個(gè)父類，然后是本類的初始化。而

24、C+的機(jī)制又是只有在父類成分初始化完畢以后才去處理子類成分的初始化工作，換句話說，如果父類的成分沒有初始化完畢，它壓根就不會(huì)去管子類的初始化工作。因?yàn)槟阍诟割惖臉?gòu)造函數(shù)中調(diào)用了虛擬函數(shù)，而這個(gè)虛擬函數(shù)一般在父類中是不進(jìn)行實(shí)現(xiàn)的。鄙人以為，一個(gè)函數(shù)之所以被調(diào)用肯定是因?yàn)檫@個(gè)函數(shù)是有一定的功能實(shí)現(xiàn)的，要不你調(diào)用它干嗎？我想C+的構(gòu)造函數(shù)也是這么想的。但是，你現(xiàn)在非要在本來用于初始化的構(gòu)造函數(shù)中去調(diào)用一個(gè)沒法初始化virtual函數(shù)，C+就認(rèn)為這個(gè)對(duì)象的父類成分還沒有初始化完畢，現(xiàn)在不能去初始化子類成分。所以，即使你現(xiàn)在聲明了一個(gè)子類對(duì)象，子類中的成分還是沒有得到初始化，所以就會(huì)出現(xiàn)不可預(yù)知的后果。

25、C+對(duì)未定位的成員變量是采取無視的態(tài)度的，因?yàn)檫€沒輪到你，你給我一邊涼快去。在構(gòu)造函數(shù)期間無視，在析構(gòu)函數(shù)期間也是無視。而析構(gòu)的順序又是先子類再父類，因?yàn)閷?duì)象的子類成分被無視，只有父類成分被析構(gòu)，所以那些未定義的成員變量自始至終都是未定義的，你也不知道它們最終會(huì)怎樣。為了證實(shí)這一點(diǎn)請(qǐng)看下面的例子:2 -classbase3 H.4 public；5|base()display();cout*Thisisbase,endl;(?virtualvoiddisplay();virtualvciddisplay10;S|virtualbase()displayl();coutThisisbase,en

26、dl;9 private:01：1-classchiIdipublicbaseor3public:child():strin(OK)coutThisischild/endlvoidchiIddisplay()coutXstrinendl；):cliildOcou.twThisischiId,w正在生限代碼.obj:trrorLNK2019無電爵？i的樸邦行號(hào),inbLicrrirHslmidbsss：:duDlsytvtill*?方#.幡hsMRUhEEHZJ,衡3考4函JH.KAH.obj.mrUE01B無去由而的外部審烏publicrlrtitlveldtMinllbu*.UxplcjlC

27、nidJ*(，di號(hào)IwLQb爾啊JAIJDC口，該籽號(hào)在畫.TP.VtnpConsalAfiLicttiHilDilutCousdLApplLC4tl4DltxaCtLilrrorI2KL1S0E十無法鄴卜金4-lPihin4.用Eii4.且育rid.劇以4njK看到這個(gè)結(jié)果，我不得不說現(xiàn)在的編譯器已經(jīng)很智能了，它直接把它攔下來在介紹與本原則有關(guān)的內(nèi)容時(shí)，作者舉了一個(gè)應(yīng)用場(chǎng)景。那就是當(dāng)類中有多個(gè)不同版本的構(gòu)造函數(shù)，它們的共同的初始化代碼都統(tǒng)一放到一個(gè)初始化成員函數(shù)里面了，并且這個(gè)初始化成員函數(shù)調(diào)用了一個(gè)virtual成員函數(shù)，并且這個(gè)virtual成員函數(shù)會(huì)有一定的實(shí)現(xiàn)代碼。當(dāng)你建立子類對(duì)象

28、時(shí)卻調(diào)用了錯(cuò)誤的virtual成員函數(shù)。在此作者并沒有詳細(xì)地解釋是為什么，但他給出了一種解決辦法。那就是在子類的構(gòu)造函數(shù)的初始化成員列表中調(diào)用父類的構(gòu)造函數(shù)去初始化對(duì)象中父類的部分，當(dāng)然了，這時(shí)父類中的那個(gè)virtual函數(shù)你要改成非virtual函數(shù)了。在這里作者使用了一個(gè)技巧，他不是在成員初始化列表直接把父類成分所需的東西直接給它，而是通過一個(gè)輔助函數(shù)返回一個(gè)值給父類進(jìn)行初始化，這樣寫比較方便也比較可讀。而且，這個(gè)輔助函數(shù)的是一個(gè)static類型。static類型的成員函數(shù)是靜態(tài)成員函數(shù)，它的類的對(duì)象實(shí)例化之前就已經(jīng)被實(shí)例化，換句話說它跟類中其他的成員不發(fā)生關(guān)系。另外，子類對(duì)象的父類成分是

29、在子類成分之前先被實(shí)例化，而在子類對(duì)象實(shí)例化的中間也就是父類成分正在實(shí)例化，還沒輪到子類成分實(shí)例化之前，子類中的成員函數(shù)啥的是未定義的，也就工作不了。而此時(shí)static成員函數(shù)卻能工作，這有助于對(duì)象中父類成分的實(shí)例化，所以把此輔助函數(shù)設(shè)置為static類型。原貝U10:令operator=返回個(gè)referenceto*this原貝U11:在operator=中處理“自我賦值”在這篇博文里面我打算寫兩個(gè)EffectiveC+中的原則，因?yàn)榈谝粋€(gè)原則太短了?，F(xiàn)在介紹第一個(gè)原則：條款10,此條款旨在說明在你自己編寫的賦值操作符=一定要返回該左值的引用。具體來說就是返回*this。這很好解釋，因?yàn)閠h

30、is是指向本對(duì)象的指針，那么*this就是該對(duì)象的本身實(shí)體了。而你現(xiàn)在返回的只不過是該實(shí)體的一個(gè)代表符號(hào)而已。現(xiàn)在一般的賦值操作符都采用這個(gè)原則，雖然不是強(qiáng)制的，但是大家都遵守。下面來對(duì)條款11做一些介紹。條款11的內(nèi)容很簡(jiǎn)單，就是一定要妥善處理賦值操作符=的自我賦值問題，就是自己給自己賦值的情況。那么這又是為什么呢？因?yàn)樵谀承r(shí)候你要編寫用來管理資源的類，那你知道一個(gè)資源不用了就要釋放掉，以便留給下一個(gè)需要該資源的對(duì)象。不過，這是很合理的。但是，假設(shè)當(dāng)前占用該資源的對(duì)恰好是用來賦值的右值，也就是它倆其實(shí)是一個(gè)東東。如果還是按照上面處理的話，就會(huì)出現(xiàn)被用來賦值的右值實(shí)際上已經(jīng)啥實(shí)質(zhì)內(nèi)容都沒有了

31、，this指針指向了NULL,那就會(huì)發(fā)生錯(cuò)誤。那么怎樣處理這種情況呢？第一種方法很簡(jiǎn)單，那就是在賦值操作符的實(shí)現(xiàn)中最先判斷一下賦值的對(duì)象和被賦值的對(duì)象是不是一個(gè)，即if(this=&obj)o不過這種方法不好，因?yàn)檫@需要額外寫出一條語句，這無疑會(huì)增加運(yùn)行時(shí)間。所以實(shí)際上采用的辦法就是所謂的COPYandSWAP方法。什么意思呢？首先賦值一份右值，生成一個(gè)COPY,然后用*this與這個(gè)COPY進(jìn)行SWAP,那么就可以完美解決自我賦值的問題。因?yàn)榧热皇荂OPY那么原來那個(gè)右值就沒有改變，而this原本是空的，它和那個(gè)COPY交換以后，那個(gè)COPY就變成了NULL,而this的內(nèi)容就成了COPY,

32、也就是原來的那個(gè)右值的值了。還有一種方法就是直接利用賦值操作符重載函數(shù)的傳參機(jī)制是傳值這一特性，直接傳進(jìn)來一個(gè)COPYo該方法可行，但是作者不提倡，它說這樣做的話清晰性變差了，我的這個(gè)清晰性大概就是可讀性吧。不過，我倒覺得沒啥。他又說這種方法有時(shí)候可能更高效。原則12:復(fù)制對(duì)象時(shí)勿忘其每一個(gè)成分這個(gè)原則是EffectiveC+中第12個(gè)原則，這原則主要涉及到兩個(gè)方面：1、自定義的COPY構(gòu)造函數(shù)和賦值操作符一定要卻把本類中的所有成員，包括新增加的成員和父類的所有成員都要復(fù)制過來。2、不要嘗試COPY構(gòu)造函數(shù)和賦值操作符進(jìn)行互相調(diào)用。第1點(diǎn)沒啥好討論的，現(xiàn)在來著重討論第2點(diǎn)。咱們只討論一種情況，

33、就是copy賦值操作符去掉用copy構(gòu)造函數(shù)的情況。因?yàn)閏opy構(gòu)造函數(shù)本身就已經(jīng)把復(fù)制了一個(gè)副本，換句話說它自身已經(jīng)生成了一個(gè)嶄新的對(duì)象。而copy賦值操作符是把傳進(jìn)來的對(duì)象賦給這個(gè)嶄新的對(duì)象，那不就是試圖在構(gòu)造一個(gè)已經(jīng)存在的對(duì)象了嗎，這很荒謬。同理copy構(gòu)造函數(shù)去掉用copy賦值操作符同樣荒謬。所以作者建議方法是把它們共同的代碼放到第3個(gè)函數(shù)中，通常這個(gè)函數(shù)被命名為init。原則13:以對(duì)象管理資源這是EffectiveC+中提到的第13個(gè)原則。資源的管理這一主題從宏觀上來講就是你申請(qǐng)了資源，就一定要釋放。你不釋放會(huì)造成內(nèi)存泄露，資源泄露，你釋放多了有可能導(dǎo)致程序行為異常。所以簡(jiǎn)而言之就

34、是你申請(qǐng)了多少個(gè)資源就釋放多少個(gè)資源就行了。可是你在編程的過程難免會(huì)忘掉或者沒有處理好資源釋放的過程，那么本原則就是告訴你如何去控制資源的釋放的。作者的經(jīng)驗(yàn)之談就是以對(duì)象作為資源的載體進(jìn)行傳遞以代替用單個(gè)語句去實(shí)現(xiàn)資源的管理過程。因?yàn)樵谶@個(gè)過程中，程序流說不定就可能被return拐走，被作為異常拋出，被continue或者break跳過，當(dāng)然還有那幾乎被摒棄的goto語句等等，而沒有到達(dá)delete。因?yàn)閷?duì)象本身有構(gòu)造函數(shù)和析構(gòu)函數(shù)，而且它會(huì)在對(duì)象的生存期末尾自動(dòng)調(diào)用析構(gòu)函數(shù)來釋放資源，從而不會(huì)造成資源泄露的情況。其實(shí)，我感覺此條款著重強(qiáng)調(diào)的是釋放資源的重要性，但是它也強(qiáng)調(diào)在取得資源的時(shí)候馬上

35、就進(jìn)行初始化。而對(duì)于操縱對(duì)象作者又極力推薦了兩種智能指針：auto_ptr,shared_ptr。這兩個(gè)指針都會(huì)在資源使用結(jié)束后自動(dòng)銷毀它們，而不用你管。auto_ptr的簡(jiǎn)單用法如下：Basebobj=newBase;aut1rBase)ptb(bobj):它有個(gè)特性，那就是一旦用這種指針指向某資源，那就不能有多個(gè)auto_ptr再去指向它了。如果已經(jīng)有一個(gè)指針指向了某資源，你再用新指針指向這個(gè)指針的話，就指針就被自動(dòng)設(shè)為NULL。shared_ptr叫“引用計(jì)數(shù)型指針”，它與auto_ptr的不同之處在于它能記錄到底有多少個(gè)對(duì)象指向某資源，但是它無法解決環(huán)狀引用，就是兩個(gè)沒用的指針互指。不

36、過，一般情況下，智能指針里面裝的都是一個(gè)函數(shù)，這個(gè)函數(shù)返回一個(gè)對(duì)象的引用，并完成該對(duì)象的初始化工作。tr1:shared_ptrptb(factory();其中factory。函數(shù)負(fù)責(zé)初始化并返回管理資源的對(duì)象的引用。原則14:在資源管理類中小心COPYING行為這是EffectiveC+中第14個(gè)原則。本原則闡述了資源管理類往往遵循RAR原則，就是“資源在構(gòu)造期間獲得，在析構(gòu)期間釋放”。因?yàn)槭且脤?duì)象來承載資源的，而本原則考慮的是如果對(duì)這種對(duì)像進(jìn)行復(fù)制要怎樣處理。因?yàn)檫@種管理資源的對(duì)象在復(fù)制的過程中很少COPY所謂的“同步化基礎(chǔ)器物”，據(jù)我的理解就是構(gòu)造和析構(gòu)函數(shù)這里的問題，當(dāng)然我的理解可能

37、不對(duì)。所以可能出現(xiàn)COPY過來的資源不能及時(shí)釋放掉。作者給出的4個(gè)解決上述問題的辦法：1、壓根就不復(fù)制資源管理對(duì)象，這就不會(huì)有問題了嘛；2、采用“引用計(jì)數(shù)法”，即要達(dá)到COPY多少對(duì)象就釋放多少對(duì)象。這往往要用到shared_ptr；3、COPY要拷貝的全面，即在該類的所有繼承體系中的類的成分都COPY過來；4、保持資源的獨(dú)一性，即它不會(huì)有多分COPY,而這往往要用到auto_ptr原則15:在資源管理類中提供對(duì)原始資源的訪問這是EffectiveC+中第15條原則，我感覺非常抽象，理解起來很費(fèi)勁，那我就邊理解邊寫博客吧。首先你要明白啥叫原始資源，其實(shí)確切的概念我也說不準(zhǔn)，但是你可以簡(jiǎn)單地理解

38、為被資源管理類管理的資源。管理資源要使用資源管理類，通常這個(gè)類被稱為RAR類，在理想的情況下，你總是試圖使用RAR類來進(jìn)行資源管理，但是世事無常，總有一些API(ApplicationProgrammingInterface)會(huì)直接調(diào)用原始資源，它們會(huì)繞過RAII類，而這不符合你的原則，而你又不得不去用。那么本原則會(huì)叫你處理這種情況的一些方法。作者舉了兩個(gè)例子：1、通過傳遞資源管理類的對(duì)象的某些方法間接傳遞一份原始資源的COPY,這樣真正的原始資源不會(huì)得到改變。那就需要RAH類提供一個(gè)接口使對(duì)象能夠暴露出其內(nèi)所含的原始資源。而這通常是通過顯式轉(zhuǎn)換和隱式轉(zhuǎn)換來實(shí)現(xiàn)的。書中仍然是以智能指針auto

39、_ptr和shared_ptr為例加以說明，它們提供接口get來顯式獲取原始資源指針，另外還通過重載，和.來隱式獲取原始資源。2、作者又舉了一個(gè)字體調(diào)用的例子。字體本身是一種原始資源，我們創(chuàng)建了一個(gè)類用來管理字體。因?yàn)檫@種原始資源比較特殊應(yīng)用場(chǎng)合也很多，所以存在讓資源管理類提供一個(gè)向外界開放的接口的必要性，外界通過調(diào)用這個(gè)接口從而使用字體這種原始資源。又因?yàn)樽罱K是要使用這種原始資源的，所以必然會(huì)調(diào)用字體的類型，從而這就存在一個(gè)類型轉(zhuǎn)換的過程。同理，作者有提供了顯式和隱式轉(zhuǎn)換兩種轉(zhuǎn)換手段。顯式轉(zhuǎn)換自不必提，其實(shí)也是get,它極大地減少了資源泄露的可能性。而隱式轉(zhuǎn)換可以自動(dòng)轉(zhuǎn)換為原始資源類型，但是

40、這存在一個(gè)問題。那便是如果用戶現(xiàn)在就是想使用一個(gè)資源管理類RAR的對(duì)象，那沒辦法他現(xiàn)在必須轉(zhuǎn)換為原始資源類型才能使用。而這隱含的兇兆就是如果你不經(jīng)意間刪除了RAR對(duì)象，那也就意外地刪除了原始資源的對(duì)象，那么你轉(zhuǎn)換過來的也就沒了?？偨Y(jié)一下，作者強(qiáng)調(diào)無論是顯示還是隱式轉(zhuǎn)換都是要視情況而定的，沒有完全的絕對(duì)。另外，RAR是的職責(zé)是資源管理重在資源釋放，雖然訪問原始資源突破了類的封裝特性，但是這不是RAR的首要存在意義。原貝U16:成對(duì)使用new和delete時(shí)要采用相同形式這個(gè)原則太簡(jiǎn)單了。當(dāng)你new一個(gè)數(shù)組的時(shí)候你要使用delete釋放，當(dāng)你new一個(gè)指針的時(shí)候，你要使用delete釋放。如果搭配

41、錯(cuò)了，后果都是未定義的。這其中的原理，只要你懂得new和delete是操作符，并且把內(nèi)存分配看成對(duì)象來處理，并會(huì)調(diào)用構(gòu)造和析構(gòu)函數(shù)就會(huì)明白了。原則17：以獨(dú)立語句將newed對(duì)象置入智能指針這是EffectiveC+中第17個(gè)原則，作者以一個(gè)示例形象地說明了這一點(diǎn)。有一個(gè)資源處理函數(shù)A,這個(gè)函數(shù)中接收兩個(gè)參數(shù)，它們分別是shared_ptr類型的指針和一個(gè)整形參數(shù)。但是，因?yàn)橛脤?duì)象來管理資源的原則，所以在這里首先有了一個(gè)資源管理類的對(duì)象，并且想把它作為A的第一個(gè)參數(shù)傳進(jìn)去，而A的第二個(gè)參數(shù)用一個(gè)能返回整形參數(shù)的成員函數(shù)B作為實(shí)參傳進(jìn)來。程序員為了圖省事，他直接在A的第一個(gè)參數(shù)的位置上new了一

42、個(gè)對(duì)象C,這個(gè)對(duì)象當(dāng)然就是資源管理類的類型了，但是A接受的是智能指針類型，所以他還在此基礎(chǔ)上進(jìn)行強(qiáng)制類型轉(zhuǎn)換到智能指針類型。這里還要介紹一個(gè)機(jī)制，那就是編譯器在產(chǎn)生函數(shù)調(diào)用碼之前，首先要對(duì)實(shí)參進(jìn)行核算。那么在核算期問，上述內(nèi)容就可以分成3步：1、new對(duì)象C;2、調(diào)用B;3、強(qiáng)制把C轉(zhuǎn)換成shared_ptr類型。在上述三個(gè)步驟中，1和3的順序是確定的，那就是1在先3在后。但是2卻不一定了，這是根據(jù)語言和編譯器的不同而異的，所以它們的順序可能是213、123、132。但是在123的情況下，如果調(diào)用B的過程發(fā)生了異常，導(dǎo)致程序終止，而newC返回的指針會(huì)丟失。又因?yàn)閟hared_ptr是用來防止

43、資源泄露的，那么我們的目的沒有達(dá)到，new出來的C還是泄露了。所以作者在此原則中想著重強(qiáng)調(diào)的是，你最好不要在調(diào)用函數(shù)的過程中直接在參數(shù)列表里面進(jìn)行new啊，類型轉(zhuǎn)換之類的操作，一旦發(fā)生資源泄露難以察覺，所以你最好把這些都放在函數(shù)調(diào)用之前的單獨(dú)語句里面。原則18:讓接口容易被正確使用，不易被誤用這是EffectiveC+中的第18條原則。1、作者在本原則中舉了一個(gè)函數(shù)接口的例子，在一般的情況下，用戶可能錯(cuò)誤地輸入了參數(shù)，而導(dǎo)致程序運(yùn)行不正確。針對(duì)這種情況作者推薦采用導(dǎo)入新類型來解決此問題。而這些類型，你可以使用結(jié)構(gòu)體、枚舉類型和帶有特定返回值的成員函數(shù)等來實(shí)現(xiàn)。而帶有特定返回值的成員函數(shù)一般來講

44、是以函數(shù)體帶對(duì)象。2、再有就是，作為接口設(shè)計(jì)者，你要限制用戶能做什么不能做什么。比如說不讓用戶去染指資源管理的任務(wù)。3、讓你接口提供的行為與內(nèi)置類型的一般性行為一致。因?yàn)橛脩艨傁矚g對(duì)他們熟悉的東西反復(fù)用，并且喜歡套用在新的東西上。所以這樣做不僅可以讓你的接口更快被用戶接受，還不容易犯錯(cuò)。在這里作者舉了泛型算法的例子。4、讓接口對(duì)客戶提出最少的要求。許多接口總是要求用戶注意這注意那，要求一多，用戶就容易頭暈，這樣使用接口就更容易出錯(cuò)。所以一定要讓接口被傻瓜式地使用。在這里作者又舉了智能指針的例子。原貝U19:設(shè)計(jì)class猶如設(shè)計(jì)type英文是：Treatclassdesignastypedes

45、ign。這是EffectiveC+中第19個(gè)原則。對(duì)類的設(shè)計(jì)歸根結(jié)底可以歸結(jié)為類型的設(shè)計(jì)，因?yàn)轭愐彩且环N類型的存在。該原則是若干個(gè)原則的集合，而這些原則是設(shè)計(jì)一個(gè)類需要遵循的。這些原則具體如下：1、類對(duì)象的創(chuàng)建和銷毀如何進(jìn)行；2、類對(duì)象賦值和初始化的區(qū)別是什么；3、類對(duì)象在何時(shí)進(jìn)行值傳遞；4、類對(duì)象所能接受的值，不能接受哪些值，如何讓用戶容易使用，不容易犯錯(cuò)；5、類對(duì)象需要考慮的繼承體系；6、類對(duì)象的類型轉(zhuǎn)換該如何實(shí)現(xiàn)。比如資源處理類的對(duì)象；7、對(duì)類對(duì)象來說那些操作符是必要的；8、什么樣的編譯器自動(dòng)生成的或者已經(jīng)存在的成員函數(shù)你應(yīng)該自己重寫并取而代之；9、該類中哪些成員能提供給外部；10、哪些

46、是新類的未聲明接口；（這個(gè)目前我不太懂）11、你是否要定義很多類型？如果是，你還不去寫個(gè)泛型類。否則，你只寫一個(gè)type就好了；12、你真的有必要定義一個(gè)新類型嗎？原則20:寧以引用傳遞代替值傳遞這是EffectiveC+中第20個(gè)原則。對(duì)于類對(duì)象而言，采用值傳遞是非常不明智的，因?yàn)樗鼤?huì)涉及到COPY構(gòu)造函數(shù)和析構(gòu)函數(shù)的調(diào)用，如果你COPY的那個(gè)對(duì)象還包含了其他類的對(duì)象，那就會(huì)涉及到更多的函數(shù)調(diào)用，而且這是呈指數(shù)級(jí)增長(zhǎng)的。而采用const&不僅極大地提高了效率而且還沒有任何構(gòu)造函數(shù)和析構(gòu)函數(shù)的調(diào)用。而之所以采用const則是由于先前的原則3.另外采用const&可以避免對(duì)象切割問題，雖然這個(gè)問

47、題我還沒認(rèn)識(shí)到那么深刻。當(dāng)一個(gè)子類對(duì)象采用值傳遞方式被調(diào)用，但是被調(diào)用時(shí)的類型要求是父類類型時(shí)，那么這時(shí)父類的COPY構(gòu)造函數(shù)會(huì)被調(diào)用，不要以為這種情況不能發(fā)生，記住這正是多態(tài)的體現(xiàn)，而父類類型不過是個(gè)接口。這樣做的話，該對(duì)象本身的子類特性就會(huì)被無視。引用的底層是用指針來實(shí)現(xiàn)的，所以你會(huì)發(fā)現(xiàn)引用和指針的行為有些相仿。所以對(duì)于內(nèi)置類型，如果你以值彳遞的話效率會(huì)高些，比如說VS中指針占4個(gè)字節(jié)，而一個(gè)char占1個(gè)字節(jié)。另外對(duì)于STL迭代器和函數(shù)，都被設(shè)計(jì)為采用以值傳遞，這是合理的，為什么呢，答案在原則1。但是不能因?yàn)閷?duì)象小就采用值傳遞，這是因?yàn)橐环矫鎸?duì)象雖小但牽連廣泛，它所涉及的COPY構(gòu)造函數(shù)

48、和析構(gòu)函數(shù)也不可小覷。另一方面，小對(duì)象也不排除將來因?yàn)樾枨蟮母淖兌兇蟮膬A向。原則21:必須返回對(duì)象時(shí)，別妄想返回其引用EffectiveC+中第21個(gè)原則，因?yàn)橐檬且赶蚰骋汛嬖诘膶?duì)象的，但如果該對(duì)象某一瞬間突然消失了，這個(gè)引用被架空了，那就出錯(cuò)了。為了證實(shí)這一點(diǎn)作者舉了一個(gè)有理數(shù)相乘的例子。有這個(gè)一個(gè)有理數(shù)類，其中有一個(gè)有理數(shù)相乘的成員函數(shù)，該成員函數(shù)返回該有理數(shù)類的對(duì)象。在此例中該對(duì)象是一個(gè)本地對(duì)象，什么叫本地對(duì)象呢？就是一個(gè)普通的，局部的對(duì)象，它隨著作用域的結(jié)束而被自動(dòng)銷毀。因?yàn)榫邆溥@一性質(zhì)，一旦你把這個(gè)函數(shù)的返回值賦給某一變量，然后該函數(shù)使命完成被自動(dòng)銷毀，那么它所返回的對(duì)象也就被

49、自動(dòng)銷毀了，那么被賦值的變量的行為就未定義了。然后作者又舉了動(dòng)態(tài)分配對(duì)象的例子。因?yàn)槭莕ew一個(gè)對(duì)象出來，所以它肯定是要調(diào)用構(gòu)造函數(shù)進(jìn)行初始化工作的，但是你往往找不到一個(gè)合理的時(shí)機(jī)進(jìn)行析構(gòu)工作，從而導(dǎo)致資源泄露。因?yàn)樯鲜鰞蓚€(gè)例子都是因?yàn)闉楸镜貙?duì)象調(diào)用構(gòu)造函數(shù)而導(dǎo)致的，那么如果把本地變量寫成static的不就避免了構(gòu)造函數(shù)和析構(gòu)函數(shù)的問題了么。作者的回答是no。因?yàn)閟tatic對(duì)象是靜態(tài)分配，它在內(nèi)存中的位置是固定的，這樣多個(gè)操作對(duì)static對(duì)象進(jìn)行修改，static對(duì)象最后的內(nèi)容是最后修改的那個(gè)內(nèi)容，基于此種性質(zhì)。如果你的業(yè)務(wù)邏輯是多個(gè)對(duì)象之間才存在的，那么這樣做的后果肯定不是你想要的。最后

50、作者給出了自己的建議一一你既然要返回一個(gè)對(duì)象，那就直接返回一個(gè)對(duì)象。原則22:將成員變量聲明為private這是EffectiveC+中第22個(gè)原則，原話是Declaredatamembersprivate,即把數(shù)據(jù)成員稱名為私有的訪問權(quán)限。為什么要這樣做？先說public,public是提供用戶的接口，它根本不具備封裝特性。從實(shí)際來看，被聲明為public的都是成員函數(shù)，用戶通過操作成員函數(shù)來操作類內(nèi)的成員，而至于說這個(gè)接口的內(nèi)部細(xì)節(jié)對(duì)于用戶來說是不可見的，其中一個(gè)典型的例子就是getter和setter的運(yùn)用。再有就是通過把public成員函數(shù)作為接口提供給用戶，那么這個(gè)接口的實(shí)現(xiàn)會(huì)有若干

51、種可能以應(yīng)對(duì)不同的需求。還是因?yàn)樗墙涌?，是給用戶使用的，所以它不能變來變?nèi)サ模駝t你叫用戶怎么用。所以一旦某個(gè)成員函數(shù)被聲明為public的，那么一般情況下它就不能再有任何變化了，當(dāng)然這個(gè)變化是從用戶的角度來看。從而推出越是廣泛使用的類，public成員聲明就越不能改變。在這里有個(gè)普遍的準(zhǔn)則，那就是封裝的越好，改變成員時(shí)所破壞的代碼量就越少。protected并不比public封裝性更好，因?yàn)槟愀淖僷ublic只是改變用戶代碼，而你改變protected則可能導(dǎo)致所有子類的代碼的破壞，它倆的代碼破壞量都不可估量，后者更甚。所以成員一旦聲明為protected和public那就意味著它們應(yīng)該是

52、永遠(yuǎn)不變的。所以從封裝的角度講只有兩中訪問權(quán)限可言，那就是private封裝和其他不封裝。原貝U23:寧以非member、非friend替換member函數(shù)這是EffectiveC+中第23條原則的內(nèi)容，我感到很奇怪，成員函數(shù)調(diào)用本類的成員怎么了？難道這還不夠封裝嗎？看下面的解釋吧。類中可能存在一系列函數(shù)用來處理一系列操作，而這一系列函數(shù)可以放在類中某一成員函數(shù)中一起執(zhí)行，但是也可以放在一個(gè)非成員函數(shù)中一起執(zhí)行。那么從封裝性上來講哪一個(gè)好呢？答案是非成員函數(shù)，這是因?yàn)槌蓡T函數(shù)還可以訪問類中的私有成員，但是非成員函數(shù)連私有成員都訪問不了，所以非成員函數(shù)的封裝性更好。要知道越多東西被封裝，就會(huì)有更

53、大的余地在不為人知的情況下更改被封裝的數(shù)據(jù)，在這里友元函數(shù)和成員函數(shù)一樣，所以本原則推崇的是非友元函數(shù)和非成員函數(shù)。這對(duì)于那些純面向?qū)ο笳Z言，像JAVA,而言很不幸，因?yàn)樗鼈儧]有獨(dú)立的函數(shù)存在。所以在這種情況下可以考慮寫一個(gè)工具類，在此類中添加函數(shù)，這樣這些函數(shù)就不是成員函數(shù)了。而C+的做法是把這些獨(dú)立的函數(shù)和被操作的類放在同一命名空間下。本原則這樣做的另一個(gè)原因是出于可擴(kuò)展原則。因?yàn)橥瓿赡骋惶囟üδ芸赡苄枰幌盗械暮瘮?shù)，但是你可能需要完成很多功能，而這些功能都屬于同一個(gè)工程。這個(gè)時(shí)候你可以為這個(gè)工程明明一個(gè)名字空間，然后把每個(gè)功能寫在一個(gè)獨(dú)立的頭文件里面，因?yàn)樗鼈児餐`屬于同一個(gè)命名空間，所

54、以在某個(gè)頭文件中你就可以把操作那一系列成員函數(shù)的非成員非友元函數(shù)也寫在同一頭文件同一命名空間下。這樣做既降低了編譯相依性也提高程序擴(kuò)展性。原則24:若所有參數(shù)皆需要類型轉(zhuǎn)換，請(qǐng)為此采用非member函數(shù)這是EffectiveC+中第24個(gè)原則，即非成員函數(shù)能夠完美解決題目中所敘述的情景。作者以一個(gè)有理數(shù)類的例子來詮釋本原則所述內(nèi)容。這個(gè)例子大致是這樣的，這個(gè)有理數(shù)類有一個(gè)帶有默認(rèn)值參數(shù)的構(gòu)造函數(shù)，并且也有一個(gè)重載的乘法操作符，并且這個(gè)重載操作符函數(shù)只接受一個(gè)有理數(shù)類的對(duì)象。現(xiàn)在在它參數(shù)的位置上放上一個(gè)整數(shù)，因?yàn)闃?gòu)造函數(shù)并非顯示，所以它允許將這個(gè)整數(shù)隱式轉(zhuǎn)換成該類的類型而參與運(yùn)算。但是奇怪的現(xiàn)象

55、來了，因?yàn)檫@個(gè)重載操作符是單目操作符，這時(shí)出現(xiàn)了一個(gè)賦值語句,result=oneHalf*2;這個(gè)*就是這個(gè)單目操作符，oneHalf是一個(gè)有理數(shù)類對(duì)象，2是整數(shù)，2可以被隱式轉(zhuǎn)換成有理數(shù)類型。但是下面這個(gè)表達(dá)式result=2*oneHalf;從邏輯上將實(shí)現(xiàn)的功能是一樣的，但是它確報(bào)錯(cuò)，這是為啥呢？那是因?yàn)檫@個(gè)*的函數(shù)原型如下所示：constRationaloperator*(constRationalsrhs)const;.T因?yàn)?并不在參數(shù)列表中，根本不存在類型轉(zhuǎn)換，而又因?yàn)樗蟮氖莾蓚€(gè)有理數(shù)類型參與運(yùn)算，因此2壓根不符合類型要求，所以會(huì)報(bào)錯(cuò)。而這就是所謂的只有被列于參數(shù)列表內(nèi)，這個(gè)參數(shù)才是隱式轉(zhuǎn)換的合格參與者。那這里你一定會(huì)冒出一個(gè)疑問，既然參數(shù)列表里面只有一個(gè)參數(shù)，那你就改寫一下這個(gè)重載操作符的函數(shù)唄，這樣兩個(gè)參數(shù)不就都能進(jìn)行隱式轉(zhuǎn)換了嗎？嗯，這個(gè)想法是好的，