? ? ? ? 假設我們有個函數(shù)用來揭示處理程序的優(yōu)先權，另一個函數(shù)用來在某動態(tài)分配所得的Widget 上進行某些帶有優(yōu)先權的處理:

int priority () ;  
void processWidget(std::trl::shared_ptr pw, int priority); 

? ? ? ?考慮如下調(diào)用:

processWidget(std::trl::shared ptr (new Widget) , priority());  

? ? ? ?令人驚訝的是，雖然我們在此使用"對象管理式資源"( object-managing resources) ，上述調(diào)用卻可能泄漏資源。

? ? ? ?編譯器產(chǎn)出一個processWidget調(diào)用碼之前，必須首先核算即將被傳遞的各個實參。上述第二實參只是一個單純的對priority 函數(shù)的調(diào)用，但第一實參std::trl::shared_ptr (new Widget) 由兩部分組成：
1.執(zhí)行"new Widget" 表達式
2.調(diào)用trl::shared_ptr 構造函數(shù)
? ? ? ?于是在調(diào)用processWidget之前，編譯器必須創(chuàng)建代碼，做以下三件事：
1.調(diào)用priority
2.執(zhí)行"new Widget"
3.調(diào)用trl::shared_ptr 構造函數(shù)
? ? ? ?C++ 編譯器以什么樣的次序完成這些事情呢?彈性很大。這和其他語言如Java和C# 不同，那兩種語言總是以特定次序完成函數(shù)參數(shù)的核算?？梢源_定的是"new Widget" 一定執(zhí)行于trl::shared_ptr 構造函數(shù)被調(diào)用之前，因為這個表達式的結(jié)果還要被傳遞作為trl::shared_ptr 構造函數(shù)的一個實參，但對priority的調(diào)用則可以排在第一或第二或第三執(zhí)行。如果編譯器選擇以第二順位執(zhí)行它(說不定可因此生成更高效的代碼，誰知道!) ，最終獲得這樣的操作序列：
1.執(zhí)行"new Widget"
2.調(diào)用priority
3.調(diào)用trl::shared_ptr構造函數(shù)
? ? ? ?現(xiàn)在請你想想，萬一對priority 的調(diào)用導致異常，會發(fā)生什么事?在此情況下"new Widget" 返回的指針將會遺失，因為它尚未被置入trl::shared_ptr 內(nèi)，后者是我們期盼用來防衛(wèi)資源泄漏的武器。是的，在對processWidget的調(diào)用過程中可能引發(fā)資源泄漏，因為在"資源被創(chuàng)建(經(jīng)由"new widget") "和"資源被轉(zhuǎn)換為資源管理對象"兩個時間點之間有可能發(fā)生異常干擾。

? ? ? ?避免這類問題的辦法很簡單:使用分離語旬，分別寫出(1)創(chuàng)建Widget ， (2) 將它置入一個智能指針內(nèi)，然后再把那個智能指針傳給processWidget:

std::trl::shared ptr pw(new Widget);// 以獨立語句將newed 對象存儲于(置入)智能指針內(nèi)  
processWidget(pw, priority());              // 這個調(diào)用動作絕不至于造成泄漏。 

? ? ? ? 以上之所以行得通，因為編譯器對于"跨越語句的各項操作"沒有重新排列的自由(只有在語句內(nèi)它才擁有那個自由度)。在上述修訂后的代碼內(nèi)，"new Widget"表達式以及"對trl::shared_ptr 構造函數(shù)的調(diào)用"這兩個動作，和"對priority的調(diào)用"是分隔開來的，位于不同語句內(nèi)，所以編譯器不得在它們之間任意選擇執(zhí)行次序。

需要記住的
以獨立語句將newed 對象存儲于(置入)智能指針內(nèi)。如果不這樣做，一旦異常被拋出，有可能導致難以察覺的資源泄漏。