其主要的類關係如下所示(省略相關的類模板引數）：

圖1



從上面的類圖可以清楚的看出shared_ptr內部含有一個指向被管理物件(managed object)T的指標以及一個__shared_count物件，__shared_count物件包含一個指向管理物件(manager object)的基類指標，管理物件(manager object)由具有原子屬性的use_count和weak_count、指向被管理物件(managed object)T的指標、以及用來銷燬被管理物件的deleter組成，以下均將用new建立後託管給shared_ptr等智慧指標管理的物件叫做被管理物件（managed object)；shared_ptr等智慧指標內部建立的用來維護被管理物件生命週期的例項叫做管理物件(manager object)：

圖2



weak_ptr內部組成與shared_ptr類似，內部同樣含有一個指向被管理物件T的指標以及一個__weak_count物件：

圖3



從圖2和圖3對比可以看出，shared_ptr與weak_ptr的差異主要是由__shared_ptr與__weak_ptr體現出來的，而__shared_ptr與__weak_ptr的差異則主要是由__shared_count與__weak_count體現出來。

通過shared_ptr的建構函式，可以發現，在建立一個shared_ptr的時候需要一個new 操作符返回被管理物件的地址來初始化shared_ptr, shared_ptr在內部會構建一個_shared_count物件，由_shared_count物件的建構函式可知，建立shared_ptr的時候也動態的建立了一個管理物件_Sp_counted_base_impl:



template<typename _Tp1> explicit __shared_ptr(_Tp1* __p)
: _M_ptr(__p), _M_refcount(__p) {
__glibcxx_function_requires(_ConvertibleConcept<_Tp1*, _Tp*>)
typedef int _IsComplete[sizeof(_Tp1)];
__enable_shared_from_this_helper(_M_refcount, __p, __p);
}

template<typename _Ptr>
__shared_count(_Ptr __p) : _M_pi(0)
{
__try
{
typedef typename std::tr1::remove_pointer<_Ptr>::type _Tp;
_M_pi = new _Sp_counted_base_impl<_Ptr, _Sp_deleter<_Tp>, _Lp>(__p, _Sp_deleter<_Tp>());
}
__catch(...)
{
delete __p;
__throw_exception_again;
}
}



shared_ptr內部包含一個指向被管理物件的指標_M_ptr, _Sp_counted_base_impl內部也含有一個指向被管理物件的指標_M_ptr， 它們是不是重複多餘了呢？

實際上不多餘，它們有各自的功能。這首先要從shared_ptr的拷貝構造或者賦值構造說起，當一個shared_ptr物件sp2是由sp1拷貝構造或者賦值構造得來的時候，實際上構造完成後sp1內部的__shared_count物件包含的指向管理物件的指標與sp2內部的__shared_count物件包含的指向管理物件的指標是相等的，也就是說當多個shared_ptr物件來管理同一個物件時，它們共同使用同一個動態分配的管理物件。這可以從下面的__share_ptr的建構函式和__shared_count的建構函式清楚的看出。



template<typename _Tp1>
__shared_ptr(const __shared_ptr<_Tp1, _Lp>& __r)
: _M_ptr(__r._M_ptr), _M_refcount(__r._M_refcount) // never throws
{__glibcxx_function_requires(_ConvertibleConcept<_Tp1*, _Tp*>)}


__shared_count&
operator=(const __shared_count& __r) // nothrow
{
_Sp_counted_base<_Lp>* __tmp = __r._M_pi;
if (__tmp != _M_pi)
{
if (__tmp != 0)
__tmp->_M_add_ref_copy();
if (_M_pi != 0)
_M_pi->_M_release();

_M_pi = __tmp;
}
}



上面說說當多個shared_ptr物件來管理同一個物件時，它們共同使用同一個動態分配的管理物件，為什麼上面給出的_shared_count的建構函式中出現了__tmp != _M_pi的情形呢？這在sp2未初始化時（_M_pi為0，_r._M_pi非0）便是這樣的情形。

更一般的，也可以考慮這樣的情形：shared_ptr例項sp1開始指向類A的例項物件a1, 另外一個shared_ptr例項sp2指向類A的例項物件a2（a1 != a2)，當把sp2賦值給sp1時便會出現上面的情形。假設初始時有且僅有一個sp1指向a1, 有且僅有一個sp2指向a2; 則賦值結束時sp1與sp2均指向a2, 沒有指標指向a1, sp1指向的a1以及其對應的管理物件均應該被析構。這在上面的程式碼中我們可以很清楚的看到：因為__tmp != _M_pi, __tmp->_M_add_ref_copy()將會增加a2的use_count的引用計數；由於a1內部的_M_pi != 0, 將會呼叫其_M_release()函式：





//************_Sp_counted_base*****************//
void
_M_add_ref_copy()
{ __gnu_cxx::__atomic_add_dispatch(&_M_use_count, 1); }


//************_Sp_counted_base*****************//
void
_M_release() // nothrow
{
// Be race-detector-friendly. For more info see bits/c++config.
_GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(&_M_use_count);
if (__gnu_cxx::__exchange_and_add_dispatch(&_M_use_count, -1) == 1)
{
_GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(&_M_use_count);
_M_dispose();
// There must be a memory barrier between dispose() and destroy()
// to ensure that the effects of dispose() are observed in the
// thread that runs destroy().
// See http://gcc.gnu.org/ml/libstdc++/2005-11/msg00136.html
if (_Mutex_base<_Lp>::_S_need_barriers)
{
__atomic_thread_fence (__ATOMIC_ACQ_REL);
}

// Be race-detector-friendly. For more info see bits/c++config.
_GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(&_M_weak_count);
if (__gnu_cxx::__exchange_and_add_dispatch(&_M_weak_count, -1) == 1)
{
_GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(&_M_weak_count);
_M_destroy();
}
}
}

//************_Sp_counted_base*****************//
// Called when _M_use_count drops to zero, to release the resources
// managed by *this.
virtual void
_M_dispose() = 0; // nothrow

// Called when _M_weak_count drops to zero.
virtual void
_M_destroy() // nothrow
{ delete this; }

//************_Sp_counted_base_impl*************//
virtual void
_M_dispose() // nothrow
{ _M_del(_M_ptr); }



_M_release()函式首先對a1的use_count減去1，並對比減操作之前的值，如果減之前是1，說明減後是0，a1沒有任何shared_ptr指標指向它了，應該將a1物件銷燬，於是呼叫_M_dispose()函式銷燬a1; 同時對a1的weak_count減去1，也對比減操作之前的值，如果減之前是1，說明減後是0，a1沒有weak_ptr指向它了，應該將管理物件銷燬，於是呼叫_M_destroy()銷燬了管理物件。這就可以解答為什麼圖2所示中shared_ptr內部含有兩個指向被管理物件的指標了：__shared_ptr直接包含的裸指標是為了實現一般指標的->,*等操作，通過__shared_count間接包含的指標是為了管理物件的生命週期，回收相關資源。

換句話說，__shared_count內部的use_count主要用來標記被管理物件的生命週期，weak_count主要用來標記管理物件的生命週期。

當一個shared_ptr超出作用域被銷燬時，它會呼叫其_share_count的_M_release()對use_count和weak_count進行自減並判斷是否需要釋放管理物件和被管理物件，這是RAII原理的核心體現：



~__shared_count() // nothrow
{
if (_M_pi != 0)
_M_pi->_M_release();
}



對於weak_ptr, 其對應的__weak_count的拷貝建構函式如下:



//************_Sp_counted_base*****************//
void
_M_weak_add_ref() // nothrow
{ __gnu_cxx::__atomic_add_dispatch(&_M_weak_count, 1); }

//************_Sp_counted_base*****************//
void
_M_weak_release() // nothrow
{
// Be race-detector-friendly. For more info see bits/c++config.
_GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(&_M_weak_count);
if (__gnu_cxx::__exchange_and_add_dispatch(&_M_weak_count, -1) == 1)
{
_GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(&_M_weak_count);
if (_Mutex_base<_Lp>::_S_need_barriers)
{
// See _M_release(),
// destroy() must observe results of dispose()
__atomic_thread_fence (__ATOMIC_ACQ_REL);
}
_M_destroy();
}
}

__weak_count<_Lp>&
operator=(const __shared_count<_Lp>& __r) // nothrow
{
_Sp_counted_base<_Lp>* __tmp = __r._M_pi;
if (__tmp != 0)
__tmp->_M_weak_add_ref();

if (_M_pi != 0)
_M_pi->_M_weak_release();

_M_pi = __tmp;

return *this;
}

__weak_count<_Lp>&
operator=(const __weak_count<_Lp>& __r) // nothrow
{
_Sp_counted_base<_Lp>* __tmp = __r._M_pi;
if (__tmp != 0)
__tmp->_M_weak_add_ref();
if (_M_pi != 0)
_M_pi->_M_weak_release();
_M_pi = __tmp;

return *this;
}

__weak_count<_Lp>&
operator=(const __shared_count<_Lp>& __r) // nothrow
{
_Sp_counted_base<_Lp>* __tmp = __r._M_pi;
if (__tmp != 0)
__tmp->_M_weak_add_ref();
if (_M_pi != 0)
_M_pi->_M_weak_release();
_M_pi = __tmp;
return *this;
}

~__weak_count() // nothrow
{
if (_M_pi != 0)
_M_pi->_M_weak_release();
}



從上面可以看出:

__weak_count相關的賦值拷貝以及解構函式均只會影響到weak_count的值，對use_count沒有影響；當weak_count為0時，釋放管理物件。也就是說__weak_ptr不影響被管理物件的生命週期。同時由於__weak_ptr沒有像__shared_ptr那樣實現*，->等常見指標相關操作符，__weak_ptr不能直接操作被管理物件；
__weak_count自身間的賦值以及__shared_count對__weak_count的賦值時，它們都具有同樣的指向管理物件的指標；也就是說當多個__weak_ptr和__shared_ptr指向同一個被管理物件時，它們共享同一個管理物件，這就保證了可以通過__weak_ptr可以判斷__shared_ptr指向的被管理物件是否存在以及獲取到被管理物件的指標。



__shared_ptr與__weak_ptr在管理同一物件時，它們間的關係如下圖4所示：

圖4



由於weak_ptr不能直接操作被管理物件但其仍然持有指向被管理物件的指標（用來初始化內部的__weak_count物件），weak_ptr與被管理物件用虛線聯接。

_weak_ptr有幾個重要的成員函式：通過expired()方法來判斷物件是否過期（已經被釋放）；通過use_count()方法返回目前有多少個__shared_ptr物件指向被管理物件；通過lock()方法返回一個指向被管理物件的__shared_ptr指標，呼叫者可以通過這個__shared_ptr指標來操縱被管理物件而不用擔心資源洩漏；



/*************_weak_ptr*************************/
long
use_count() const // never throws
{ return _M_refcount._M_get_use_count(); }

bool
expired() const // never throws
{ return _M_refcount._M_get_use_count() == 0; }

__shared_ptr<_Tp, _Lp>
lock() const // never throws
{
#ifdef __GTHREADS
// Optimization: avoid throw overhead.
if (expired())
return __shared_ptr<element_type, _Lp>();

__try
{
return __shared_ptr<element_type, _Lp>(*this);
}
__catch(const bad_weak_ptr&)
{
// Q: How can we get here?
// A: Another thread may have invalidated r after the
// use_count test above.
return __shared_ptr<element_type, _Lp>();
}

#else
// Optimization: avoid try/catch overhead when single threaded.
return expired() ? __shared_ptr<element_type, _Lp>()
: __shared_ptr<element_type, _Lp>(*this);

#endif
} // XXX MT




當然shared_ptr也不是萬能的，使用的時候也要注意到它給程式設計師挖的一個大坑：shared_ptr能夠管理物件的生命週期，負責物件資源釋放，其前提條件是所有shared_ptr共用同一個管理物件。如果多個shared_ptr使用多個管理物件來管理同一個被管理物件，這些管理物件在use_count為0時均會釋放被管理物件，將會造成多個管理物件多次釋放被管理物件，造成twice delete的堆錯誤。下面的例子在單獨使用裸指標的時候沒有問題，採用shared_ptr將會出現twice delete的問題：





class Thing {
public:
void foo();
void defrangulate();
};
void transmogrify(Thing *);
int main()
{
Thing * t1 = new Thing;
t1->foo();
...
delete t1; // done with the object
}
...
void Thing::foo()
{
// we need to transmogrify this object
transmogrify(this);
}
void transmogrify(Thing * ptr)
{
ptr->defrangulate();
/* etc. */
}
//***** Use shared_ptr***************************//
class Thing {
public:
void foo();
void defrangulate();
};
void transmogrify(shared_ptr<Thing>);
int main()
{
shared_ptr<Thing> t1(new Thing); // create manager object A for the Thing
t1->foo();
...
// Thing is supposed to get deleted when t1 goes out of scope
}
void Thing::foo()
{
// we need to transmogrify this object
shared_ptr<Thing> sp_for_this(this); // create manager object B for the Thing
transmogrify(sp_for_this);

// Thing is supposed to get deleted when sp_for_this and other shared_ptr goes out of scope
}
void transmogrify(shared_ptr<Thing> ptr)
{
ptr->defrangulate();
/* etc. */
}



上面註釋處分別建立了兩個shared_ptr指標t1，sp_for_this, 它們各自有自己的管理物件，但被管理的堆記憶體卻是一樣的，這就導致在t1和sp_for_this析構時，它們各自的管理物件均會析構被管理物件，造成twice delete。



怎樣解決上面這一廣泛存在問題：當一個物件M建立後，如果一個函式f（另一個類的成員函式或是其它自由函式）的形參為M型別的智慧指標，如何在物件M內部將物件M的指標作為實參傳遞給該函式f ? C++引入了enable_shared_from_this利用weak_ptr的特性解決了這一問題。其基本思想是通過M繼承模板類enable_shared_from_this，這樣物件M內部將會有一個__weak_ptr指標_M_weak_this，在第一次建立指向M的shared_ptr Pt時，通過模板特化，將會初始化_M_weak_this;這樣M內部也會產生一個指向自身的weak_ptr，並且該weak_ptr內部的管理物件與Pt的管理物件是相同的（這可以從weak_ptr內部的_M_assign函式看出）。





// Friend of enable_shared_from_this.
template<typename _Tp1, typename _Tp2>
void __enable_shared_from_this_helper(const __shared_count<>&, const enable_shared_from_this<_Tp1>*, const _Tp2*);


template<typename _Tp1>
explicit __shared_ptr(_Tp1* __p)
: _M_ptr(__p), _M_refcount(__p)
{
__glibcxx_function_requires(_ConvertibleConcept<_Tp1*, _Tp*>) typedef int _IsComplete[sizeof(_Tp1)];
__enable_shared_from_this_helper(_M_refcount, __p, __p);

}

template<typename _Tp>
class enable_shared_from_this
{
protected:
enable_shared_from_this() { }

enable_shared_from_this(const enable_shared_from_this&) { }

enable_shared_from_this&
operator=(const enable_shared_from_this&)
{ return *this; }

~enable_shared_from_this() { }

public:
shared_ptr<_Tp>
shared_from_this()
{ return shared_ptr<_Tp>(this->_M_weak_this); }

shared_ptr<const _Tp>
shared_from_this() const
{ return shared_ptr<const _Tp>(this->_M_weak_this); }

private:
template<typename _Tp1>
void
_M_weak_assign(_Tp1* __p, const __shared_count<>& __n) const
{ _M_weak_this._M_assign(__p, __n); }

template<typename _Tp1>
friend void
__enable_shared_from_this_helper(const __shared_count<>& __pn, const enable_shared_from_this* __pe, const _Tp1* __px)
{
if (__pe != 0)
__pe->_M_weak_assign(const_cast<_Tp1*>(__px), __pn);
}

mutable weak_ptr<_Tp> _M_weak_this;
};

_M_assign(_Tp* __ptr, const __shared_count<_Lp>& __refcount)
{
_M_ptr = __ptr;
_M_refcount = __refcount;
}







這樣，在M內部，當需要傳遞指向M的智慧指標時，可以通過繼承而來的shared_from_this方法獲取到指向M的智慧指標而不會發生記憶體洩漏。上面示例中改寫後的正確程式碼為：





class Thing : public enable_shared_from_this<Thing> {
public:
void foo();
void defrangulate();
};
int main()
{
// The following starts a manager object for the Thing and also
// initializes the weak_ptr member that is now part of the Thing and share same manager object.
shared_ptr<Thing> t1(new Thing);
t1->foo();
...
}
void Thing::foo()
{
// get a shared_ptr from the weak_ptr in this object
shared_ptr<Thing> sp_this = shared_from_this();
transmogrify(sp_this);
}
void transmogrify(shared_ptr<Thing> ptr)
{
ptr->defrangulate();
/* etc. */
}



解決了所有的坑，shared_ptr是不是就十全十美了呢？當然不是，shared_ptr也存在不足：在採用shared_ptr<M> p(new M);形式建立p來管理M時，我們實際發現這中間有兩次的動態記憶體分配：一次為建立被管理物件M，一次為建立管理物件；而記憶體分配通常是比較昂貴的操作。



如果頻繁的需要建立指向多個不同物件的智慧指標，可以採用shared_ptr<M> p(make_shared<M>);的方式，採用這種方式系統將會分配一大塊記憶體同時存放管理物件和被管理物件，這就避免了上面所說的二次記憶體分配的問題，同時程式中也不會出現new操作符，符合"no naked new!"的程式設計倡導。當然這也有缺點，如果所有指向該物件的智慧指標都銷燬了，儘管物件的解構函式會被呼叫，析構被管理物件，但是如果還有weak_ptr指向該塊物件所在的記憶體，存放管理物件的部分記憶體仍將不會被釋放，因而導致在所有其他weak_ptr銷燬前整塊記憶體（儘管被管理物件已經析構了）將不會進入系統的記憶體池迴圈使用。


————————————————
版權宣告：本文為CSDN博主「ithiker」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https://blog.csdn.net/ithiker/article/details/51532484