========================
Effective C++   實(shí)現(xiàn)
書(shū)作者：Scott Meyers
原筆記作者：Justin
========================

Item 26 ： 盡可能延后變量定義式的出現(xiàn)時(shí)間
--------------------------------------------------
 tag:
 ·盡可能延后變量定義式的出現(xiàn)，以增加程序的清晰度并改善程序效率。
 
 定義變量包含了該變量對(duì)象的構(gòu)造操作，如果因?yàn)槟硞€(gè)原因(如拋出異常，條件語(yǔ)句未執(zhí)行等)而沒(méi)有真正用到這個(gè)變量，那么構(gòu)造該變量所耗費(fèi)的時(shí)間和資源就白費(fèi)了。
 在即將使用變量前再定義它對(duì)理解代碼也有好處：要想知道某個(gè)變量時(shí)做什么用的？讀接下來(lái)的代碼便是。

 思考題，以及答案：
 //方法A：循環(huán)外定義
 Widget w;
 for (int i = 0; i < n; ++i){
    w = some_value_dependent_on_i;      
    //..                                 
 }                                   

 //方法B:循環(huán)內(nèi)定義
 for (int i = 0; i < n; ++i) {
 Widget w(some_value_dependent_on_i);
 //..
 }
  方法A調(diào)用了1次構(gòu)造函數(shù)、1次析構(gòu)函數(shù)、n次拷貝函數(shù)；
  方法B調(diào)用了n次析構(gòu)函數(shù)、n次析構(gòu)函數(shù)。
  
  當(dāng) 拷貝操作的開(kāi)銷(xiāo) 比 構(gòu)造-析構(gòu)操作 要廉價(jià)的時(shí)候，一般來(lái)說(shuō)A方法是上選。
  但是A方法中對(duì)象的作用域比B方法中更大，也就違背了代碼的集中性和可維護(hù)性原則。
  因此，除非
     拷貝操作比構(gòu)造-析構(gòu)操作開(kāi)銷(xiāo)小，并且此部分代碼對(duì)性能(performance)要求很高，(此時(shí)選擇為A)
  否則B方法還是更合理。

Item 27 ： 少做轉(zhuǎn)型動(dòng)作
--------------------------------------------------
 tag: cast 轉(zhuǎn)型    const_cast    dynamic_cast    reinterpret_cast    static_cast
 
 ·盡量避免轉(zhuǎn)型，特別是注重效率的代碼中避免 dynamic_casts.盡量將要轉(zhuǎn)型的設(shè)計(jì)轉(zhuǎn)化為無(wú)需轉(zhuǎn)型。
 ·若轉(zhuǎn)型必須，試著將它隱藏于某個(gè)函數(shù)背后。客戶隨后可以隨時(shí)調(diào)用該函數(shù)，而不需將轉(zhuǎn)型放進(jìn)他們自己的代碼中。
 ·另可使用 C++ style轉(zhuǎn)型，也不要使用舊式轉(zhuǎn)型。前者更容易分辨。
 
 類(lèi)型轉(zhuǎn)換的三種形式(前面兩種都是C風(fēng)格的舊式類(lèi)型轉(zhuǎn)換)：
  (T)expression
  T(expression)
  C++ Style:
   const_cast：設(shè)置或是去除對(duì)象的const屬性。
   dynamic_cast：主要用于繼承關(guān)系層次中的向上、向下轉(zhuǎn)換，以及類(lèi)之間的交叉轉(zhuǎn)換。會(huì)進(jìn)行轉(zhuǎn)換安全性檢查。
   static_cast：可用于內(nèi)置類(lèi)型的轉(zhuǎn)換，以及繼承關(guān)系層次中的向上轉(zhuǎn)換。沒(méi)有轉(zhuǎn)換安全性檢查。
   reinterpret_cast：簡(jiǎn)單的強(qiáng)制將一個(gè)指針轉(zhuǎn)換為另外一種指針或整數(shù)類(lèi)型，不做任何檢查。
 
 類(lèi)型轉(zhuǎn)換還可能引發(fā)額外的代碼運(yùn)行。比如說(shuō)dynamic_cast就會(huì)通過(guò)調(diào)用strcmp來(lái)比較類(lèi)的名稱(chēng)，從而完成繼承關(guān)系中不同類(lèi)對(duì)象的轉(zhuǎn)換，這個(gè)時(shí)候就不僅僅是簡(jiǎn)單的變變類(lèi)型了。因此，說(shuō)“類(lèi)型轉(zhuǎn)換僅是告訴編譯器把一種類(lèi)型的數(shù)據(jù)當(dāng)成另外一種來(lái)參與計(jì)算”其實(shí)是一個(gè)理解上的誤區(qū)。
 類(lèi)型轉(zhuǎn)換也有可能帶來(lái)額外開(kāi)銷(xiāo)：比如書(shū)中用static_cast進(jìn)行的繼承關(guān)系的向上轉(zhuǎn)換，就會(huì)自作主張地生成一個(gè)臨時(shí)的對(duì)象。

 dynamic_cast 通常是在一個(gè)認(rèn)定為 derived class 對(duì)象上執(zhí)行 derived class操作函數(shù)，但手上只有一個(gè)“指向base”的pointer或reference。
  可以用以下兩種方法來(lái)避免這個(gè)問(wèn)題：
  1. 使用容器并在其中存儲(chǔ)直接指向 derived class 對(duì)象的指針（通常為智能指針），以消除通過(guò)base class接口處理對(duì)象的需要。
  2. 在base class內(nèi)提供virtual函數(shù)做你想對(duì)各個(gè)derived classes做的事。
 要避免所謂的“連串（cascading）dynamic_casts”
 
 在C++中，兩個(gè)指向同一個(gè)對(duì)象的不同指針可能擁有不同的地址值。
 因此，不僅要盡可能的避免轉(zhuǎn)換類(lèi)型，而且在不得不使用類(lèi)型轉(zhuǎn)換的時(shí)候，也應(yīng)該考慮將轉(zhuǎn)換的代碼用函數(shù)封裝起來(lái)。

Item 28 ： 避免返回 handles 指向?qū)ο髢?nèi)部成分
--------------------------------------------------
 tag: 返回值
 
 避免返回 handles（包括reference、pointer、iterator）指向?qū)ο髢?nèi)部。
 增加封裝性，幫助const成員函數(shù)的行為像個(gè)const，并將發(fā)生“懸垂handles”的可能性降至最低。
 

 如果只需要讀訪問(wèn)，就使用const的返回值，不要開(kāi)放寫(xiě)的權(quán)限。
 有可能產(chǎn)生懸垂指針(dangling pointer)也是暴露對(duì)象內(nèi)部成員handles的后果之一。
 
 一個(gè)返回對(duì)象內(nèi)部成員的函數(shù)，在用戶不正確使用的情況下，就有可能產(chǎn)生懸垂指針。
  class AClass{//..};
  class BClass{
  //..
  const AClass& FuncReturningARef();
  //..
  }

  //a possible user's code
  BClass AnObjectOfB;
  const AClass *pAClass = &(AnObjectOfB.FunReturningARef());
  //After the call pAClass becomes a dangeling pointer..
 

Item 29 ： 編寫(xiě)對(duì)異常免疫(exception-safe)的代碼
--------------------------------------------------
 tag: Exception safety
 
 ·Exception safety functions即使發(fā)生異常也不回泄露字元或允許任何數(shù)據(jù)結(jié)構(gòu)敗壞。區(qū)分為三種可能的保證：基本型、強(qiáng)類(lèi)型、不拋出異常型
 ·強(qiáng)烈保證型通常能以 copy-and-swap 實(shí)現(xiàn)，但強(qiáng)烈保證兵匪對(duì)所有函數(shù)都可實(shí)現(xiàn)或具備現(xiàn)實(shí)意義。
 ·函數(shù)提供的“Exception-safe保證”通常只等于其所調(diào)用之各個(gè)函數(shù)的“Exception-safe保證"中的最弱者。

 對(duì)異常免疫的函數(shù)在異常發(fā)生的時(shí)候應(yīng)該具備兩個(gè)特征：
  不泄漏任何資源(內(nèi)存、鎖等等)
  不造成任何數(shù)據(jù)結(jié)構(gòu)的損壞
 并能夠提供至少以下保證中的一項(xiàng)：

 Exception-safe functions 提供以下三個(gè)保證之一：
  基本的保證：當(dāng)異常拋出時(shí)，程序中的對(duì)象、數(shù)據(jù)免遭破壞。
  較強(qiáng)的保證：當(dāng)異常拋出時(shí)，程序的狀態(tài)不會(huì)被改變。若成功調(diào)用函數(shù)，則系統(tǒng)進(jìn)入成功后的狀態(tài)；如果函數(shù)中因異常而出錯(cuò)，系統(tǒng)應(yīng)該留在調(diào)用函數(shù)前的狀態(tài)：
  最強(qiáng)的保證：不會(huì)有異常拋出。例如對(duì)內(nèi)置類(lèi)型的操作就不會(huì)拋出異常。這是最理想的，但也很難做到。更多的函數(shù)只能在前兩者中做一選擇。

 為了能夠提供較強(qiáng)的保證，也即系統(tǒng)的狀態(tài)不因異常拋出與否而變化，大師又重新提出了“先拷貝后交換”(copy-and-swap)這一方法論來(lái)。
 用不那么嚴(yán)謹(jǐn)?shù)恼f(shuō)法：為了避免在操作對(duì)象時(shí)觸發(fā)異常影響系統(tǒng)狀態(tài)，“先拷貝后交換”先是創(chuàng)建了一個(gè)臨時(shí)對(duì)象，將所有的操作都施加在該臨時(shí)對(duì)象上。如果沒(méi)有出錯(cuò)，把這個(gè)處理過(guò)的臨時(shí)對(duì)象和真正需要處理的對(duì)象交換一通，算是順利完成任務(wù)；如果有錯(cuò)并拋出了異常，原系統(tǒng)狀態(tài)也不會(huì)被影響，因?yàn)檎嬲枰幚淼膶?duì)象根本沒(méi)有被動(dòng)過(guò)。
 當(dāng)然，天下沒(méi)有免費(fèi)的午餐。
 “先拷貝后交換”不僅耗費(fèi)了一個(gè)臨時(shí)對(duì)象的存儲(chǔ)代價(jià)，同時(shí)支出的還有后面交換對(duì)象時(shí)的時(shí)間和資源開(kāi)銷(xiāo)。因此，對(duì)異常免疫的較強(qiáng)保證是很好很強(qiáng)大，但是實(shí)際中并不是任何時(shí)候都需要做到那么高的保證。殺雞豈需用牛刀？

 最后要提醒的是，對(duì)異常免疫的函數(shù)也符合“短板理論”：木桶能裝的水與其最短的那塊木板有關(guān)，函數(shù)對(duì)異常免疫的程度也由函數(shù)中程度最低的代碼(包括其調(diào)用的函數(shù))決定。某個(gè)函數(shù)如果調(diào)用了另外一個(gè)一出現(xiàn)異常就崩潰的函數(shù)，那么這個(gè)函數(shù)就不能提供基本的異常免疫保證。

Item 30 ： 透徹了解 inlining
--------------------------------------------------
 tag: inline
 ·將大多數(shù) inlining 限制在小型、被頻繁調(diào)用的函數(shù)身上。可使日后的調(diào)用過(guò)程和二進(jìn)制升級(jí)更容易，也使程序的速度提升機(jī)會(huì)更大。
 ·不要只因?yàn)?function templates 出現(xiàn)在頭文件，就將他們聲明為 inline.
 
 使用內(nèi)聯(lián)函數(shù)(inline function)可以省去一般函數(shù)調(diào)用的入棧操作開(kāi)銷(xiāo)，比宏(macro)要好用。從編譯器的角度來(lái)看，沒(méi)有函數(shù)調(diào)用的代碼要更容易優(yōu)化。
 但是天下沒(méi)有免費(fèi)的午餐，以空間換時(shí)間的內(nèi)聯(lián)函數(shù)同時(shí)也帶來(lái)了更大的程序占用空間，更甚者還會(huì)因?yàn)檫@變大的代碼空間導(dǎo)致額外的內(nèi)存換頁(yè)操作，降低指令緩存(instruction cache)的命中率……這些都是使用內(nèi)聯(lián)函數(shù)需要考慮到的負(fù)面影響。(Scott還是辯證地提醒了一點(diǎn)：當(dāng)內(nèi)聯(lián)函數(shù)非常短小時(shí)，相比一般意義上的函數(shù)調(diào)用，它能夠幫助編譯器生成更小的最終代碼和運(yùn)行時(shí)更高的指令緩存命中率)

 內(nèi)聯(lián)函數(shù)的聲明可以是顯式的：使用inline關(guān)鍵字；也可以是隱式的：在類(lèi)的定義中定義函數(shù)。

 內(nèi)聯(lián)函數(shù)一般而言都是定義在頭文件中，這是因?yàn)榇蠖鄶?shù)編譯器的內(nèi)聯(lián)動(dòng)作都是發(fā)生在編譯過(guò)程中。(也有著鏈接甚至是運(yùn)行中才進(jìn)行內(nèi)聯(lián)的，但是俺們這里隨大流，講主要矛盾)
 雖然內(nèi)聯(lián)函數(shù)和函數(shù)模板有一點(diǎn)相似：它們都幾乎定義在頭文件中，但是這兩者之間沒(méi)有必然聯(lián)系，而非有的程序員想的那樣“函數(shù)模板一定是內(nèi)聯(lián)的”)

 內(nèi)聯(lián)函數(shù)的定義僅僅是對(duì)編譯器提出內(nèi)聯(lián)的請(qǐng)求。編譯器完全有可能忽視這個(gè)請(qǐng)求，于是某“內(nèi)聯(lián)函數(shù)”有可能在最后還是生成了一般函數(shù)的代碼：

  請(qǐng)求內(nèi)聯(lián)的函數(shù)有可能太過(guò)于復(fù)雜
  請(qǐng)求內(nèi)聯(lián)的函數(shù)有可能是虛函數(shù)(虛函數(shù)的真正實(shí)體要在運(yùn)行時(shí)才能得知，讓編譯器編譯階段去做內(nèi)聯(lián)實(shí)在有點(diǎn)強(qiáng)人所難)
  請(qǐng)求內(nèi)聯(lián)的函數(shù)沒(méi)什么問(wèn)題，但是在代碼中有用函數(shù)指針的方式調(diào)用該函數(shù)(這樣編譯器也沒(méi)辦法，如果不生成一般函數(shù)哪來(lái)的函數(shù)指針？)
  這些情況下確實(shí)不應(yīng)該把函數(shù)作為內(nèi)聯(lián)函數(shù)。一個(gè)“內(nèi)聯(lián)函數(shù)”是否最終生成了內(nèi)聯(lián)函數(shù)，還得編譯器說(shuō)了算。
 然而編譯器并不是總能幫助我們做出正確的決定，還有一些情況是需要我們自己做出判斷的：

 請(qǐng)求內(nèi)聯(lián)的函數(shù)是構(gòu)造/析構(gòu)函數(shù)(表面上看起來(lái)某個(gè)構(gòu)造/析構(gòu)函數(shù)很短小甚至是空的，但是為了構(gòu)造/析構(gòu)類(lèi)中的其他成員，編譯器有可能會(huì)“自覺(jué)”地寫(xiě)入必要的代碼，這樣的構(gòu)造/析構(gòu)函數(shù)就有可能不適合再做內(nèi)聯(lián)了)這一點(diǎn)原文中有更詳細(xì)的說(shuō)明。
 當(dāng)編寫(xiě)支持庫(kù)時(shí)(library)也不建議使用內(nèi)聯(lián)函數(shù)，因?yàn)橐坏┯脩羰褂昧诉@些含有內(nèi)聯(lián)函數(shù)的庫(kù)并編譯了自己的程序，這些內(nèi)聯(lián)函數(shù)就已經(jīng)“寫(xiě)死”在他們的程序中了。當(dāng)日后對(duì)原先的庫(kù)做了更新修改，用戶就必須重新編譯整個(gè)程序才能用上新的補(bǔ)丁。而一般的函數(shù)就不會(huì)有這個(gè)問(wèn)題：他們是動(dòng)態(tài)鏈接的，用戶根本感覺(jué)不到任何改動(dòng)。
 考慮到很多調(diào)試器(debugger)無(wú)法調(diào)試內(nèi)聯(lián)函數(shù)(本來(lái)就沒(méi)有這么一個(gè)“函數(shù)”，叫人家怎么設(shè)斷點(diǎn)？)，在調(diào)試版本中也不建議使用內(nèi)聯(lián)函數(shù)。
 有那么多需要注意的地方，大師最后總結(jié)了一下：用好內(nèi)聯(lián)函數(shù)的第一步就是：不用內(nèi)聯(lián)函數(shù)。并沒(méi)有那么多的函數(shù)真正需要內(nèi)聯(lián)，因?yàn)?0%的程序運(yùn)行時(shí)間都是花在了20%的代碼中。第二步是把內(nèi)聯(lián)函數(shù)當(dāng)成是手工優(yōu)化的手段，僅僅在非常需要效率和優(yōu)化的代碼中使用內(nèi)聯(lián)。

Item 31 ： 將文件間的編譯依存關(guān)系降至最低
--------------------------------------------------
 tag: Handle class，Interface classes ,  接口類(lèi) 實(shí)現(xiàn)類(lèi)，
 ·相依于聲明式，不要相依于定義式。兩個(gè)手段來(lái)實(shí)現(xiàn)：Handle classes 和 Interface classes.
 ·程序庫(kù)頭文件應(yīng)該以 “ 完全且僅有聲明式 ”(full and declaration-only forms)的形式存在，不論是否涉及 templates.
 
 大師說(shuō)了，C++的設(shè)計(jì)還是有缺陷的：它無(wú)法把接口(interface)的設(shè)計(jì)和實(shí)現(xiàn)(implementation)的設(shè)計(jì)完全劃分開(kāi)來(lái)。
 比如說(shuō)在一個(gè)類(lèi)的(接口)聲明當(dāng)中，總是或多或少的會(huì)泄漏一些實(shí)現(xiàn)上的細(xì)節(jié)，雖然這樣做與接口的設(shè)計(jì)并沒(méi)有太多聯(lián)系。

  class  AClass  {
  public :
     void  interface_1();
     std::string  interface_2();
  private :
     //  implementation details are leaking as below..
     std::string  internalData_1;
     BClass internalData_2;
  }   

 往往還需要引用其他頭文件中相關(guān)對(duì)象的定義(如下面的代碼)，從而產(chǎn)生了對(duì)這些頭文件的(在編譯時(shí)的)依賴。因此每次這些文件中的某個(gè)有變化時(shí)，依賴它的所有文件都需要重新編譯。
  #include  < string >
 #include  " BClass.h "  //
 
 【注意】這里貌似邏輯不是很順：就算沒(méi)有那些私有成員的聲明，接口函數(shù)的返回值如果是string或是BClass等類(lèi)型，不還是一樣需要依賴引用其他頭文件嗎？
 這是兩種不一樣的情況，實(shí)現(xiàn)和接口。
  前面說(shuō)的實(shí)現(xiàn)細(xì)節(jié)的泄漏是會(huì)導(dǎo)致編譯依賴的，因?yàn)榫幾g器需要了解這些類(lèi)型對(duì)象的大小進(jìn)而為其分配內(nèi)存空間；
  但是接口，比如說(shuō)函數(shù)的返回值或是參數(shù)表中的參數(shù)，就不需要編譯器去考慮分配內(nèi)存的問(wèn)題，因此也就沒(méi)有所謂的編譯依賴了。

 將類(lèi)分割為兩個(gè)classes，一個(gè)只提供接口，另一個(gè)負(fù)責(zé)實(shí)現(xiàn)該接口。
   class  AClassImpl 
   {
   private :
      //  implementation details are moved here..
      std::string  internalData_1;
      BClass internalData_2;
   }
  
   class  AClass 
   {
   public :
      void  interface_1();
      std::string  interface_2();
   private :
      //  there is only a pointer to implementation
      std::tr1::shared_ptr < AClassImpl >  pImpl;
  }
  
   // a constructor: instantiations of AClass and AClassImpl should always be bound together.
   AClass::AClass( // ..) : pImpl(new AClassImpl( // ..))
   {   } 

 分離的關(guān)鍵在于以“聲明的依存性”替換“定義的依存性”：讓頭文件盡可能自我滿足，如果不行，就讓它與其他文件內(nèi)的聲明式（而非定義式）相依：
 ·若使用 object references 或 object pointers 可以完成任務(wù)，就不要使用 objects.但如果要定義某類(lèi)型的object，就需要用到定義式，。
 ·盡量以class聲明式替換class定義式。
 ·為聲明式和定義式提供不同的頭文件。

 第二種方法中，抽象類(lèi)/接口類(lèi)提供了所有接口的純虛函數(shù)形式：會(huì)有該類(lèi)的子類(lèi)去實(shí)現(xiàn)這些接口。
 在抽象類(lèi)/接口類(lèi)中還會(huì)有一個(gè)靜態(tài)(static)的工廠函數(shù)(比如create()/produce()/factory()……），這個(gè)函數(shù)實(shí)際上起到了構(gòu)造函數(shù)的作用，它“制造”出子類(lèi)對(duì)象來(lái)完成真正的任務(wù)，同時(shí)返回這個(gè)對(duì)象的指針(通常是智能指針如shared_ptr)。憑借這個(gè)返回的指針就可以進(jìn)行正常的操作，同時(shí)不會(huì)有編譯依賴的擔(dān)心。一個(gè)簡(jiǎn)陋的代碼見(jiàn)下：

  class  AClass: public  AClassFactory  {
  public :
      AClass()   {}
      void  interface_1();
      std:: string  interface_2();
      virtual   ~ AClass();
  }
 
  class  AClassFactory  {
  public :
      virtual   void  interface_1()  =   0 ;
      virtual  std::string  interface_2()  =   0 ;
      virtual   ~AClassFactory()  { /* .. */ }
      static  std::tr1::shared_ptr < AClassFactory >  Produce( /* .. */ )
      {
         // this factory function could be more complicated in practice..
         return  std::tr1::shared_ptr < AClassFactory > ( new  AClass);
      }
  }
 
 
  // AClassFactory could be used in this way..
  std::tr1::shared_ptr < AClassFactory >  pAClassObject;
  pAClassObject  =  AClassFactory::Produce( /* .. */ );
  // pAClassObject->..