學習筆記：shared_ptr陷阱
睿豐德科技 專注RFID識別技術和條碼識別技術與管理軟件的集成項目。質量追溯系統、MES系統、金蝶與條碼系統對接、用友與條碼系統對接
條款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共存就把人搞糊涂了。RFID管理系統集成商 RFID中間件 條碼系統中間層 物聯網軟件集成