毫無疑問，shared_ptr的功能不可謂不強(qiáng)大，設(shè)計不可謂不精巧，它的抽象級別不是一般的高，不僅要管理一般的C++內(nèi)存資源，更染指其他的非C++資源，比如文件、比如連接、……，只要給它一個支點(diǎn)（釋放資源的函數(shù)），不僅如此，還能頑強(qiáng)地生存于各種惡劣的環(huán)境，好比多線程、引用循環(huán)。當(dāng)然，代價是有的，它背地里做了很多不為人知的勾當(dāng)，表面上僅僅一行的帶有構(gòu)造函數(shù)shared_ptr的定義代碼，編譯器卻要很無奈地生成一個莫明其妙的多態(tài)模板類（_Ref_count_base的繼承類，帶有虛函數(shù)表，意味著不能內(nèi)聯(lián)，用以在恰當(dāng)?shù)臅r機(jī)，釋放資源），更別提要多了一堆指令，當(dāng)然，在當(dāng)今硬件性能蓬勃發(fā)展的美好時代，這點(diǎn)代價根本就不算什么，比之于那些什么所謂的虛擬機(jī)，甚至可以忽略不計。但是，總是有那么一批老古董，總會強(qiáng)迫假想自己寫的程序會運(yùn)行于各種資源非常苛刻的環(huán)境下，內(nèi)心就是沒法原諒shared_ptr所帶來的極細(xì)微的損失。好比區(qū)區(qū)在下，每一次一用到shared_ptr，心里的那種負(fù)罪感啊，又多了幾條廢指令，又浪費(fèi)多了十幾個的堆字節(jié)，是否將生成內(nèi)存碎片啊。終于有一刻頂不住了啦，去你媽的shared_ptr，老子不過想讓你老老實(shí)實(shí)的代理內(nèi)存資源，本本分分地做好你的分內(nèi)之事，不勞你費(fèi)心照顧其他的系統(tǒng)資源對象，那些場合本座自然有更好的解決方式。于是，制造輪子的悲劇又再次誕生了，雖然，他們一直在內(nèi)心深處抵制新輪子的愚蠢行為，但是，……，只能說，知我者謂我心憂，不知我者謂我何求。
每次想到shared_ptr要new一個_Ref_count_base的對象來管理計數(shù)，有人就恨得牙根發(fā)癢，巴不得把_Ref_count_base的數(shù)據(jù)成員搬過來，放之于那個要管理的對象的身上，以減少一小塊內(nèi)存。假如，客戶傳到shared_ptr構(gòu)造函數(shù)的指針，此指針?biāo)傅膬?nèi)存，能再多幾個字節(jié)（一個字節(jié)也行，最大值255，已足矣），以供我等存放一個long型的計數(shù)器，那就好辦了。白癡也知道，這是不可能的事情。除非，此對象由shared_ptr來構(gòu)造，那么還有辦法再放多點(diǎn)額外內(nèi)存進(jìn)去。此話怎講？大家都知道，C++中， new一個對象時，即意味著兩步操作：1、分配一塊內(nèi)存；2、在此塊內(nèi)存上執(zhí)行對象的構(gòu)造函數(shù)。如果第1步的分配內(nèi)存，能作多點(diǎn)手腳，比如說，分配一塊比對象本身所占空間還要大的內(nèi)存，那么我們的shared_ptr就可以把計數(shù)器放進(jìn)對象之中了，也無須再new一個新的_Ref_count_base對象來管理計數(shù)器了。兩塊內(nèi)存，合二為一，雙劍合璧，妙哉妙哉。但，這如何做到呢？
以下，是一個類從簡單到復(fù)雜的物種進(jìn)化歷程。C++中，只要是通用類，即使再簡單的需求，要寫得可以被普遍承認(rèn)，可以高高興興地到處使用，都絕非易事。而且，更悲劇的是，辛辛苦苦，嘔心瀝血造出來的輪子，還很有可能一問世就直接被槍斃，就算能茍且活下來，也不會有車愿意組裝這一個廢輪子。
廢話不說，書接上文，很明顯，對象的new操作應(yīng)該由我們的shared_ptr來掌控。任由用戶來new，就太遲了，對象的內(nèi)存塊已經(jīng)確定下來了，沒文章可做啦。換句話說，shared_ptr必須模擬標(biāo)準(zhǔn)的new的兩在操作分配內(nèi)存和調(diào)用構(gòu)造函數(shù)。由此可知，以下所探討的shared_ptr運(yùn)用場合也很有限，只適合于那些能看到構(gòu)造函數(shù)并且知道其大小的C++類，所以，請大伙兒不要抱怨。唯其需求簡單明確，所以才能高效。
首先，用一結(jié)構(gòu)體__SharedObject來包含計數(shù)器和對象，如下所示：
struct __SharedObject
{
void* Object() // 返回對象的地址，由于不知對象的類型，所以只能是void*，表示內(nèi)存地址
{ return this+1; }
long Incref() { return InterlockedIncrement(&m_nRef); }
long Decref() { return InterlockedDecrement(&m_nRef); }
long m_nRef;
};
是否很簡陋，本座沒法也不想把它整得更加好看了。
我們的shared_ptr，就暫時叫TShared_Ptr好了，其包含的數(shù)據(jù)成員，暫時很簡單。就只有一個__SharedObject的指針而已，后面由于多繼承多態(tài)的原因，將被迫多增加一個指針。
好了，先看看TShared_Ptr的使用之道，此乃class template。由于共享對象由TShared_Ptr所造，所以，在其誕生之前，首先勢必定義一TShared_Ptr變量，好比，TShared_Ptr<int> pInt；考慮TShared_Ptr的構(gòu)造函數(shù)，如果在里面就急急忙忙給共享對象分配內(nèi)存，將沒法表達(dá)空指針這個概念，所以它的無參構(gòu)造函數(shù)只是簡單地將m_pShared置為NULL。然后，TShared_Ptr必須提供分配內(nèi)存并執(zhí)行構(gòu)造函數(shù)的操作，叫Construct吧；然后，析構(gòu)函數(shù)也絕不含糊，執(zhí)行對象的析構(gòu)函數(shù)并釋放內(nèi)存。于是，TShared_Ptr的基本代碼就出爐了。
template<typename _Ty>
class TShared_Ptr
{
public:
TShared_Ptr() {m_pShared = NULL; }
TShared_Ptr(const TShared_Ptr& _Other)
{
if (m_pShared != NULL)
{
m_pShared = const_cast<__SharedObject*>(_Other.m_pShared);
m_pShared->Incref();
}
else
m_pShared = NULL;
}
~TShared_Ptr()
{
if (m_pShared != NULL)
{
if (m_pShared->Decref() <= 0)
{
if (m_pShared->m_nRef == 0)
DestroyPtr(get());
free(m_pShared);
}
}
}
_Ty& operator*() const _THROW0() { return *get(); }
_Ty *operator->() const _THROW0(){return (get());}
void Construct()
{
::new (m_pShared->Object()) _Ty(); // 調(diào)用構(gòu)造函數(shù)
m_pShared->Incref(); // 構(gòu)造函數(shù)拋出異常，這一行將不執(zhí)行
}
void alloc() // 假設(shè)malloc總能成功
{
m_pShared = static_cast<__SharedObject*>(malloc(sizeof(_Ty)+sizeof(__SharedObject)));
m_pShared->m_nRef = 0;
}
_Ty *get() const _THROW0() { return (_Ty*)(m_pShared->Object());}
__SharedObject* m_pShared;
};
可以寫代碼測試了，
TShared_Ptr<int> pInt;
pInt.Construct();
(*pInt)++;
TShared_Ptr<int> pInt1 = pInt;
(*pInt1)++;
咦，假如共享對象的構(gòu)造函數(shù)帶有參數(shù)，咋辦呢？不要緊，重載多幾個Construct就行了，全部都是template 成員函數(shù)。由于要實(shí)現(xiàn)參數(shù)的完美轉(zhuǎn)發(fā)，又沒有C++2011的move之助，我還在堅持C++98ISO，要寫一大打呢，先示例幾個，很痛苦，或者，可通過宏來讓內(nèi)心好受一點(diǎn)。
template<typename T1>void Construct(const T1& t1);
template<typename T1>void Construct(T1& t1);
template<typename T1, typename T2>void Construct(const T1& t1, const T1& t2);
template<typename T1, typename T2>void Construct(const T1& t1, T1& t2);
template<typename T1, typename T2>void Construct(T1& t1, const T1& t2);
template<typename T1, typename T2>void Construct(T1& t1, T1& t2);
接下來就很清晰了，將shared_ptr的各種構(gòu)造、賦值函數(shù)改寫一遍就是了。然后，就可以高高興興地測試使用了。以上，是最理想環(huán)境下TShared_Ptr的很簡單的實(shí)現(xiàn)，其操作接口多么的確簡明扼要。
開始，考慮各種變態(tài)環(huán)境，其實(shí)也不變態(tài)，完全很正當(dāng)?shù)男枨蟆８鞣N也不多，就兩個而已：1、構(gòu)造函數(shù)拋出異常，這個不是問題，由于TShared_Ptr的構(gòu)造函數(shù)不拋出異常，其析構(gòu)函數(shù)將被執(zhí)行，檢查到計數(shù)器為0，所以不調(diào)用共享對象的析構(gòu)函數(shù)；
2、多繼承，這個有點(diǎn)頭痛了。先看看代碼，假設(shè) class D : public B1, public B2，B1、B2都非空類;然后，B2* pB2 = pD，可以保證，(void*)pB2的值肯定不等于pD，也即是(void*)pB2 != (void*)pD。個中原因，在下就不多說了。但是，TShared_Ptr完全沒法模擬這種特性，假如，堅持這樣用，設(shè)pD為TShared_Ptr<D> ; 然后TShared_Ptr<B2>=pD，后果將不堪設(shè)想。一切皆因TShared_Ptr只有一條指向共享對象的指針，它還須擁有指向共享對象的基類子對象的指針，為此，必須添加此指向子對象的指針m_ptr，為_Ty*類型。因此，TShared_Ptr將內(nèi)含兩個指針，大小就比普通指針大了一倍，無論如何，到此為止，不能讓它增大了。此外，TShared_Ptr增加了m_ptr成員后，還帶來一些別的好處，類型安全倒也罷了，關(guān)鍵是在VC中單步調(diào)試下，可清晰地看到共享對象的各種狀態(tài)，原來沒有m_ptr的時候，就只能悶聲發(fā)大財。
template<typename _Ty>
class TShared_Ptr
{
public:
template<typename _OtherTy>
TShared_Ptr(const TShared_Ptr<_OtherTy>& _Other)
{
m_ptr = _Other.m_ptr; // 類型安全全靠它了
m_pShared = const_cast<__SharedObject*>(_Other.m_pShared);
if (m_ptr != NULL)
m_pShared->Incref();
}
__SharedObject* m_pShared;
_Ty* m_ptr;
}; 本輪子自然不美觀，使用也頗不方便，但勝在背地里做的勾當(dāng)少，一切均在預(yù)料之中。好像多線程下，還有點(diǎn)問題，但那只是理論上的疑惑，實(shí)際運(yùn)行中，該不會那么巧吧。
咦，都什么年代，還在研究茴香豆的四種寫法，在下也承認(rèn)，確實(shí)沒啥意義，但樂趣很無窮呢，我就是喜歡。珍惜生命，遠(yuǎn)離C++。對了，想要完整的代碼嗎，沒那么容易