========================
Effective C++   資源管理類（resource-managing classes）
書作者：Scott Meyers
原筆記作者：Justin
========================

Item 13 ：以對象管理資源
---------------------------------------
 tag：auto_ptr   shared_ptr   RAII    RSCP   智能指針
 
 要利用對象來管理資源（可以是分配出來的內(nèi)存、互斥量等）。這樣可以避免因為寫代碼時的疏忽而導致的資源流失（可以是內(nèi)存的泄漏，也可能是忘了解鎖）。

 將釋放資源的代碼放在對象的析構(gòu)函數(shù)中，只要對象被析構(gòu)，就可以保證資源被完整釋放。
 C++的析構(gòu)函數(shù)自動調(diào)用機制(C++’s automatic destructor invocation)能夠保證當對象脫離控制時該對象的析構(gòu)函數(shù)被調(diào)用（比如一個對象在某函數(shù)內(nèi)部定義，那么在函數(shù)執(zhí)行結(jié)束后，這個對象的析構(gòu)函數(shù)會被自動調(diào)用以銷毀此對象）。
 是個好辦法，至少對我這樣時常丟三落四的人來說是個福音。何況這樣的對象大多數(shù)情況下不用自己寫，auto_ptr（智能指針, smart pointer的一種）就可以勝任。

  std::auto_ptr<void *>  pMem(AllocAndInitMemory());
 
 高亮的部分即說明了auto_ptr的用法，也附帶示范了所謂的RAII(Resource Acquisition Is Initialization)資源取得時機便是初始化時期。
 
 這里的auto_ptr就像是個陪女友逛街的可憐家伙，女朋友（用戶）說要什么，auto_ptr就乖乖的去買來（申請），想要用的時候就趕緊拿出來給女友用，哪怕她忘了曾經(jīng)買了某件衣服，auto_ptr還是會老老實實地送回家里，不用擔心會弄丟或是搞臟。嗯，有點做上帝的感覺吧？

 不過，沒有什么是十全十美的。大師馬上就說到了用對象管理資源的問題，好吧，應該說是需要注意的地方：
 首先不能用一個以上的對象，比如說auto_ptr，管理同一個資源。這個很好理解，就像一個漂亮的女孩子腳踏多條船（同時定義了多個auto_ptr），但是她必須要小心，不能讓多個對象參加同一個約會：今天逛街的時候喊上了小張就不能叫小王，明天一起吃飯如果約了小李就別再和小趙定時間：一個資源一次只能讓一個對象來管理。
 這樣的規(guī)則用在auto_ptr上就是書中奇怪的“=”行為：兩個auto_ptr對象A和B，A=B運算的結(jié)果是A接管了B管理的資源，B指向的是null。（如果記不起來了，具體代碼見書）這樣的行為很像是傳遞：小李陪女朋友逛完街后，送她到人民廣場，在那里小陳約好了和她一起看電影。到了人民廣場之后小陳摟著女人開心的走了，只剩下小李一個孤單的背影，杯具啊杯具……

 為了避開這種尷尬且極易被誤解的“=”操作，出現(xiàn)了以shared_ptr為代表的reference-counting smart pointer(RCSP)（引用計數(shù)型智能指針？）。它們可以“共事一夫”，由一個公用的reference counter來計數(shù)，某個shared_ptr在準備拋棄一個資源時先參考reference counter的值，如果非零，說明還有其他的“姐妹”在罩著資源，不需要也不可以釋放該資源；如果值為零，說明當前只有她一個人了，于是真正的擔當起smart pointer的責任：釋放資源。
 
  std::shared_ptr<void *>  pMem(AllocAndInitMemory());

 重點不在于是用auto_ptr還是shared_ptr還是其他的什么東東，而是要領會精神——使用對象來管理資源。比如說用string對象來管理一個字符串而不是手工申請一片內(nèi)存然后用個指針“吧唧”粘上去就開始用了。
 不能再動態(tài)分配而得的 array 上使用 auto_ptr 或 tr1::shared_ptr，因為兩者在析構(gòu)的時候調(diào)用的是delete而不是delete[].
 要擁有針對數(shù)組而設計的，可用 boost::scoped_array 和 boost::shared_array classes.
 


Item 14: 在管理類中小心 coping 行為
--------------------------------------------
 tag： RAII  
 
 RAII守則：資源在構(gòu)造期間獲得，在析構(gòu)期間釋放。
 
 RAII對象被復制：
  ·不允許拷貝。當資源本身不能復制時，對象可以說“不”。怎么做？回到Item6……
  ·使用Reference-Count（引用計數(shù)），可以用上節(jié)說到的shared_ptr來干這個事，這里順帶介紹了shared_ptr提供的一個接口：一個可以在構(gòu)造對象時定義的delete操作：如果對象是內(nèi)存就是釋放，如果對象是鎖就是解鎖。
  ·直接復制。別人有什么，你就直接原封不動也復制一份。如果是內(nèi)存的話說得過去，如果是鎖，我想還是不能這樣亂用哈。
  ·移交所有權。這個不算是真正意義的復制，移交手續(xù)而已。最典型的例子就是auto_ptr的復制行為。

Item 15： 在資源管理類中提供對原始資源的訪問
-------------------------------------------------
 tag：返回原始資源
 
 ·在使用對象管理資源的同時也要留出接口給那些需要繞過對象而直接訪問資源的人。
    
 寫個函數(shù)暴露出指向資源的指針就可以。書里講得更多的是用怎樣的函數(shù)：
 
 顯式轉(zhuǎn)換(explicit conversion)
 可以實現(xiàn)一個get函數(shù)，或是*、->運算，返回指向資源的指針。
 
 隱式的轉(zhuǎn)換函數(shù)(implicit conversion)，
 
 但是個人覺得實際工作中應該是不提倡這樣做的，因為隱式的轉(zhuǎn)換極有可能發(fā)生在編程者沒有意識的情況下，導致后面的代碼出錯。

 class Font {
 public:
 //  ..
 // implicit conversion function
   operator FontHandle() const { return f; }
 //  ..
 };
 上面代碼的應用如下，f本身為Font類型，(changeFontSize第一個參數(shù)為FontHandle)，但是由于隱式轉(zhuǎn)換，類型變成了FontHandle。

 Font f(getFont());
 int newFontSize;
 //..
 // implicitly convert Font to FontHandle
 changeFontSize(f, newFontSize);
 
 為了能兼容更多的API，需要留出接口提供對資源的直接訪問。
 隱式或顯示主要取決于RAII class 被設計執(zhí)行的特定工作，以及它被使用的狀況。
 
 
Item 16 ： 成對使用new和 delete時采用相同形式
---------------------------------------------------
 tag：  new delete

 ·用new分配一個內(nèi)存對象時，語法格式是new a;用delete釋放一個內(nèi)存對象時，語法格式是delete a;
 ·用new分配一組內(nèi)存對象時，語法格式是new a [num_of_elem]; 用delete釋放一組內(nèi)存對象時，語法格式是delete [] a;
 
 new或是delete包含了兩個階段：

 new：申請并分配內(nèi)存空間；調(diào)用構(gòu)造函數(shù)構(gòu)造即將使用空間的對象
 delete：調(diào)用析構(gòu)函數(shù)析構(gòu)使用空間的對象；釋放內(nèi)存
 
 分配內(nèi)存給一組對象的時候，編譯器一般會在這一片內(nèi)存前端(或是其他什么地方)插入一小段信息，用來標明這片內(nèi)存是給多少個對象的，然后反復調(diào)用構(gòu)造函數(shù)來創(chuàng)建這一組對象。當用delete []的時候，釋放內(nèi)存的操作就會以該信息為依據(jù)，反復調(diào)用對象的析構(gòu)函數(shù)對這組對象進行釋放。(下面的[n]就是這段信息)
 [n][MEM]
 而如果只是分配內(nèi)存給一個對象，這段信息就不存在了。直接在這片內(nèi)存上應用析構(gòu)函數(shù)。
 
 于是用delete []去釋放new的內(nèi)存，或是用delete去釋放new []的內(nèi)存，都會造成不可預計的后果。

Item 17 ： 將new語句單獨寫
----------------------------------
 tag：   newed
 
 processWidget(std::tr1::shared_ptr<Widget>(new Widget), priority());這行語句有問題，這個復雜的參數(shù)表包含了三個動作：

  ·new 一個 Widget
  ·用new的Widget做為參數(shù)執(zhí)行share_ptr的構(gòu)造函數(shù)
  ·執(zhí)行priority
 C++的某個編譯器可能為了效率而自作主張，導致這三個動作的執(zhí)行順序是不確定的！因此上面的動作執(zhí)行順序可能是這樣的：

  ·new 一個 Widget
  ·執(zhí)行priority
  ·用new的Widget做為參數(shù)執(zhí)行share_ptr的構(gòu)造函數(shù) 

 這個時候如果priority的執(zhí)行出錯而引發(fā)異常，就會發(fā)生內(nèi)存泄漏(Memory Leak)，因為new出來的Widget再也無法跟蹤了。

 而解決方法也很簡單，不要妄圖一行寫完所有程序，分開來老老實實寫就是了：

    std::tr1::shared_ptr<Widget> pw(new Widget);
    processWidget(pw, priority());  

 VC++下不會。