毫無疑問，shared_ptr的功能不可謂不強大，設計不可謂不精巧，它的抽象級別不是一般的高，不僅要管理一般的C++內存資源，更染指其他的非C++資源，比如文件、比如連接、……，只要給它一個支點（釋放資源的函數），不僅如此，還能頑強地生存于各種惡劣的環境，好比多線程、引用循環。當然，代價是有的，它背地里做了很多不為人知的勾當，表面上僅僅一行的帶有構造函數shared_ptr的定義代碼，編譯器卻要很無奈地生成一個莫明其妙的多態模板類（_Ref_count_base的繼承類，帶有虛函數表，意味著不能內聯，用以在恰當的時機，釋放資源），更別提要多了一堆指令，當然，在當今硬件性能蓬勃發展的美好時代，這點代價根本就不算什么，比之于那些什么所謂的虛擬機，甚至可以忽略不計。但是，總是有那么一批老古董，總會強迫假想自己寫的程序會運行于各種資源非常苛刻的環境下，內心就是沒法原諒shared_ptr所帶來的極細微的損失。好比區區在下，每一次一用到shared_ptr，心里的那種負罪感啊，又多了幾條廢指令，又浪費多了十幾個的堆字節，是否將生成內存碎片啊。終于有一刻頂不住了啦，去你媽的shared_ptr，老子不過想讓你老老實實的代理內存資源，本本分分地做好你的分內之事，不勞你費心照顧其他的系統資源對象，那些場合本座自然有更好的解決方式。于是，制造輪子的悲劇又再次誕生了，雖然，他們一直在內心深處抵制新輪子的愚蠢行為，但是，……，只能說，知我者謂我心憂，不知我者謂我何求。
    每次想到shared_ptr要new一個_Ref_count_base的對象來管理計數，有人就恨得牙根發癢，巴不得把_Ref_count_base的數據成員搬過來，放之于那個要管理的對象的身上，以減少一小塊內存。假如，客戶傳到shared_ptr構造函數的指針，此指針所指的內存，能再多幾個字節（一個字節也行，最大值255，已足矣），以供我等存放一個long型的計數器，那就好辦了。白癡也知道，這是不可能的事情。除非，此對象由shared_ptr來構造，那么還有辦法再放多點額外內存進去。此話怎講？大家都知道，C++中， new一個對象時，即意味著兩步操作：1、分配一塊內存；2、在此塊內存上執行對象的構造函數。如果第1步的分配內存，能作多點手腳，比如說，分配一塊比對象本身所占空間還要大的內存，那么我們的shared_ptr就可以把計數器放進對象之中了，也無須再new一個新的_Ref_count_base對象來管理計數器了。兩塊內存，合二為一，雙劍合璧，妙哉妙哉。但，這如何做到呢？
    以下，是一個類從簡單到復雜的物種進化歷程。C++中，只要是通用類，即使再簡單的需求，要寫得可以被普遍承認，可以高高興興地到處使用，都絕非易事。而且，更悲劇的是，辛辛苦苦，嘔心瀝血造出來的輪子，還很有可能一問世就直接被槍斃，就算能茍且活下來，也不會有車愿意組裝這一個廢輪子。
    廢話不說，書接上文，很明顯，對象的new操作應該由我們的shared_ptr來掌控。任由用戶來new，就太遲了，對象的內存塊已經確定下來了，沒文章可做啦。換句話說，shared_ptr必須模擬標準的new的兩在操作分配內存和調用構造函數。由此可知，以下所探討的shared_ptr運用場合也很有限，只適合于那些能看到構造函數并且知道其大小的C++類，所以，請大伙兒不要抱怨。唯其需求簡單明確，所以才能高效。
首先，用一結構體__SharedObject來包含計數器和對象，如下所示：
    是否很簡陋，本座沒法也不想把它整得更加好看了。
    我們的shared_ptr，就暫時叫TShared_Ptr好了，其包含的數據成員，暫時很簡單。就只有一個__SharedObject的指針而已，后面由于多繼承多態的原因，將被迫多增加一個指針。
    好了，先看看TShared_Ptr的使用之道，此乃class template。由于共享對象由TShared_Ptr所造，所以，在其誕生之前，首先勢必定義一TShared_Ptr變量，好比，TShared_Ptr<int> pInt；考慮TShared_Ptr的構造函數，如果在里面就急急忙忙給共享對象分配內存，將沒法表達空指針這個概念，所以它的無參構造函數只是簡單地將m_pShared置為NULL。然后，TShared_Ptr必須提供分配內存并執行構造函數的操作，叫Construct吧；然后，析構函數也絕不含糊，執行對象的析構函數并釋放內存。于是，TShared_Ptr的基本代碼就出爐了。