轉自：http://blog.sina.com.cn/s/blog_62b4e3ff0100v1tc.html 條款1：不要把一個原生指標給多個shared_ptr管理 int* ptr = new int; shared_ptr<int> p1(ptr); shared_ptr<int> p2(ptr); //logic error ptr物件被刪除了2次 這種問題比喻成“二龍治水”，在原生指標中也同樣可能發生。
條款2：不要把this指標給shared_ptr class Test{ public:     void Do(){  m_sp =  shared_ptr<Test>(this);  } private:     shared_ptr<Test> m_member_sp; };
Test* t = new Test; shared_ptr<Test> local_sp(t); p->Do();
發生什麼事呢，t物件被刪除了2次！ t物件給了local_sp管理，然後在m_sp =  shared_ptr<Test>(this)這句裡又請了一尊神來管理t。 這就發生了條款1裡“二龍治水”錯誤。
條款3：shared_ptr作為被保護的物件的成員時，小心因迴圈引用造成無法釋放資源。
物件需要相互協作，物件A需要知道物件B的地址，這樣才能給物件B發訊息（或呼叫其方法）。 設計模式中有大量例子，一個物件中有其他物件的指標。現在把原生指標替換為shared_ptr.
假設a物件中含有一個shared_ptr<B>指向b物件；假設b物件中含有一個shared_ptr<A>指向a物件 並且a，b物件都是堆中分配的。很輕易就能與他們失去最後聯絡。 考慮某個shared_ptr<A> local_a;是我們能最後一個看到a物件的共享智慧指標，其use_count==2, 因為物件b中持有a的指標。所以當local_a說再見時，local_a只是把a物件的use_count改成1。 同理b物件。然後我們再也看不到a,b的影子了，他們就靜靜的躺在堆裡，成為斷線的風箏。
解決方案是：Use weak_ptr to "break cycles."（boost文件裡寫的）或者顯示的清理
條款4：不要在函式實參裡建立shared_ptr
function ( shared_ptr<int>(new int), g( ) );  //有缺陷 可能的過程是先new int，然後調g( )，g( )發生異常，shared_ptr<int>沒有建立，int記憶體洩露
shared_ptr<int> p(new int()); f(p, g());  //Boost推薦寫法
條款5：物件內部生成shared_ptr
前面說過，不能把this指標直接扔給shared_ptr. 但是沒有禁止在物件內部生成自己的shared_ptr
//這是Boost的例子改的。 class Y: public boost::enable_shared_from_this<Y> {     boost::shared_ptr<Y> GetSelf()     {         return shared_from_this();     } };
原理是這樣的。普通的（沒有繼承enable_shared_from_this）類T的shared_ptr<T> p(new T). p作為棧物件佔8個位元組，為了記錄（new T）物件的引用計數，p會在堆上分配16個位元組以儲存 引用計數等“智慧資訊”。share_ptr沒有“嵌入(intrusive)”到T物件，或者說T物件對share_ptr毫不知
情。Y物件則不同，Y物件已經被“嵌入”了一些share_ptr相關的資訊，目的是為了找到“全域性性”的 那16位元組的本物件的“智慧資訊”。
原理說完了，就是陷阱 Y y; boost::shared_ptr<Y> p=  y.GetSelf(); //無知的程式碼，y根本就不是new出來的
Y* y = new Y; boost::shared_ptr<Y> p=  y->GetSelf(); //似是而非，仍舊程式崩盤。 Boost文件說，在呼叫shared_from_this()之前，必須存在一個正常途徑建立的shared_ptr
boost::shared_ptr<Y> spy(new Y) boost::shared_ptr<Y> p =  spy->GetSelf(); //OK
條款6 ：處理不是new的物件要小心。
int* pi = (int*)malloc(4) shared_ptr<int> sp( pi ) ; //delete馬嘴不對malloc驢頭。
條款7：多執行緒對引用計數的影響。
如果是輕量級的鎖，比如InterLockIncrement等，對程式影響不大 如果是重量級的鎖，就要考慮因為share_ptr維護引用計數而造成的上下文切換開銷。 1.33版本以後的shared_ptr對引用計數的操作使用的是Lock-Free（類似InterLockIncrement函式族） 的操作，應該效率不錯，而且能保證執行緒安全（庫必須保證其安全，程式設計師都沒有干預這些隱藏事物的機會）。 Boost文件說read，write同時對shared_ptr操作時，行為不確定。這是因為shared_ptr本身有兩個成員px，pi。 多執行緒同時對px讀寫是要出問題的。與一個int的全域性變數多執行緒讀寫會出問題的原因一樣。
條款8：物件陣列用shared_array
int* pint = new int[100]; shared_array<int> p (pint );
既然shared_ptr對應著delete；顯然需要一個delete[]對應物shared_array
條款9：學會用刪除器
struct Test_Deleter {        void  operator ()( Test* p){   ::free(p);   } }; Test* t = (Test*)malloc(sizeof(Test)); new (t) Test;
shared_ptr<Test> sp( t ,  Test_Deleter() ); //刪除器可以改變share_ptr銷燬物件行為
有了刪除器，shared_array無用武之地了。 template<class T> struct Array_Deleter {        void  operator ()( T*){   delete[] p;   } }; int* pint = new int[100]; shared_ptr<int> p (pint, Array_Deleter<int>() );
條款10：學會用分配器
存放引用計數的地方是堆記憶體，需要16-20位元組的開銷。 如果大量使用shared_ptr會造成大量記憶體碎片。 shared_ptr建構函式的第3個引數是分配器，可以解決這個問題。
shared_ptr<Test> p( (new Test), Test_Deleter(), Mallocator<Test>() ); 注意刪除器Test_Deleter是針對Test類的。分配器是針對shared_ptr內部資料的。
Mallocator<Test>()是個臨時物件（無狀態的），符合STL分配器規約。
template <typename T>  class Mallocator {      //略。。。。。。     T * allocate(const size_t n) const {         return singleton_pool<T,sizeof(T)>::malloc();     }     //略。。。。。。
Mallocator傳入Test，實際分配的型別確是 class boost::detail::sp_counted_impl_pda<class Test *,                                          struct Test_Deleter,                                          class Mallocator<class Test> > 這是用typeid(T).name()打印出來的。可能和rebind相關。
條款11 weak_ptr在使用前需要檢查合法性。 weak_ptr<K> wp; { shared_ptr<K>  sp(new K);  //sp.use_count()==1 wp = sp; //wp不會改變引用計數，所以sp.use_count()==1 shared_ptr<K> sp_ok = wp.lock(); //wp沒有過載->操作符。只能這樣取所指向的物件 } shared_ptr<K> sp_null = wp.lock(); //sp_null .use_count()==0; 因為上述程式碼中sp和sp_ok離開了作用域，其容納的K物件已經被釋放了。 得到了一個容納NULL指標的sp_null物件。在使用wp前需要呼叫wp.expired()函式判斷一下。 因為wp還仍舊存在，雖然引用計數等於0，仍有某處“全域性”性的儲存塊儲存著這個計數資訊。 直到最後一個weak_ptr物件被析構，這塊“堆”儲存塊才能被回收。否則weak_ptr無法直到自己 所容納的那個指標資源的當前狀態。
條款12 不要new shared_ptr<T>
本來shared_ptr就是為了管理指標資源的，不要又引入一個需要管理的指標資源shared_ptr<T>*
條款13  儘量不要get
class B{...}; class D : public B{ ...};  //繼承層次關係
shared_ptr<B> sp (new D);    //通過隱式轉換，儲存D的指標。 B* b = sp.get();             //shared_ptr辛辛苦苦隱藏的原生指標就這麼被刨出來了。 D* d = dynamic_cast<D*>(b);  //這是使用get的正當理由嗎？
正確的做法 shared_ptr<B> spb (new D)  ; shared_ptr<D> spd = shared_dynamic_cast<D>(spb); //變成子類的指標 shared_ptr在竭盡全力表演的像一個原生指標，原生指標能幹的事，它也基本上能幹。
另一個同get相關的錯誤 shared_ptr<T> sp(new T); shared_ptr<T> sp2( sp.get() ) ;//又一個“二龍治水”例項，指標會刪2次而錯誤。
條款14 不要memcpy shared_ptr
shared_ptr<B> sp1 (new B)  ; shared_ptr<B> sp2; memcpy(&sp2,&sp1,sizeof(shared_ptr<B>)); //sp2.use_count()==1 很顯然，不是通過正常途徑（拷貝構造，賦值運算），引用計數是不會正確增長的。
條款15 使用BOOST預定義的巨集去改變shared_ptr行為。
shared_ptr行為由類似BOOST_SP_DISABLE_THREADS這樣的巨集控制。需要去學習他們到底是幹什麼的。 大師Andrei Alexandrescu設計了一種基於模板策略設計模式的智慧指標，通過幾個模板引數去定製化 智慧指標的行為。Boost卻不以為然，官方解釋是：需要統一的介面，這樣利於大規模書寫。 smart_ptr<T,OwnershipPolicy,ConversionPolicy,CheckingPolicy,StoragePolicy> sp(new T); 上述介面缺點是外形複雜，看上去像個大花臉。優點是客戶程式設計師可以輕易的定製行為。
條款17 建構函式裡呼叫shared_from_this拋例外
class Holder:public enable_shared_from_this<Holder>{ public:     Holder() {         shared_ptr<Holder> sp = shared_from_this();         int x = sp.use_count();     } }; 同前面條款5，不符合enable_shared_from_this使用前提。
總結： 學習了一天就總結出10多條條款，長期研究一下恐怕就出現條款100了。為什麼還要使用shared_ptr呢？ 有很多開源庫用shared_ptr，而且shared_ptr具有“傳染性”（某網友語：像毒品沾上就甩不掉）， 拋開它就會有更嚴重的多龍治水現象。shared_ptr作為原生指標的替代品，能解決一定的記憶體洩露問題。 實際上初學原生指標時，每個人都遇到過野指標，刪兩次，忘記刪除等問題。學習shared_ptr也會遇到。 shared_ptr的確能改善上述問題，並不能完全解決問題。shared_ptr可能在將來佔主流，它最可能號令江湖， 否則一大堆auto_ptr,weak_ptr,原生指標，scoped_ptr共存就把人搞糊塗了。