關于相等和不等
template<class T, class U> inline bool operator==(shared_ptr<T> const & a, shared_ptr<U> const & b)
{
return a.get() == b.get();
}
template<class T, class U> inline bool operator!=(shared_ptr<T> const & a, shared_ptr<U> const & b)
{
return a.get() != b.get();
}
由此可以看出，實際上它們就是簡單的比較內部原始指針是否相等。因此可以得出這樣的判斷，對于使用==來比較的時候，以下情況下a和b會相等：
1.a、b都為空或者是都包含空指針，或者是其中之一。比如說如果a為空，b為空指針，那么也是相等的。
2.如果a和b存在著拷貝構造或者是賦值關系，那么它們也是相等的。
同時我們也應該注意到相等判斷只與內部對象的地址有關系和內部對象的值沒有關系，比如說:
shared_ptr<int> sp1 (new int (3));
shared_ptr<int> sp2 (new int (3));
由于sp1和sp2內部的指針肯定不相同，因此sp1和sp2肯定不相等。
而不等于比較簡單，就是!(a==b)。
對于STL的關聯容器，它們對于是否存在的判斷標準是等價而不是相等。而等價的定義是如此：
template <class Ty1, class Ty2>
inline bool equiv(shared_ptr<Ty1> left,
shared_ptr<Ty2> right)
{
return !(left < right) && !(right < left);
}
對于shared_ptr來說，當且僅當如下情況時，這個函數才返回true，也就是等價關系成立：
1. left和right都為空。即：left和right都使用默認構造函數構造。
2. left和right控制相同的受控源。即：left和right存在著某一方從另外一方拷貝構造或者賦值的關系。
對于等價判斷實際上我們選擇的是shared_ptr的重載<，通過查看實現源碼可以發現最終發生比較關系的是shared_count的一個成員數據指針pi_：sp_counted_base * pi_;
friend inline bool operator<(shared_count const & a, shared_count const & b)
{
return std::less<sp_counted_base *>()( a.pi_, b.pi_ );
}
因此，重載<只有當pi_不相同的時候才有可能返回true。上面的語句通常情況下等于： return a.pi_ < b.pi_。通過參考上面的判別式!(left < right) && !(right < left)我們可以知道，除非a.pi_和b.pi_相同，否則判別式!(left < right) && !(right < left)永遠不可能為true。
下面就可以把重點集中在什么時候會導致a.pi_與b.pi_相等了。
通過查看源碼我們可以發現當且僅當shared_count類對象使用默認構造的時候pi_才會被初始化為0，其它有參數的情況都會發生內存分配，返回值保存在pi_當中，先考察下面這幾個構造函數：
shared_count()
template<class Y> explicit shared_count( Y * p )
template<class P, class D> shared_count( P p, D d )
template<class P, class D, class A> shared_count( P p, D d, A a )
template<class Y> explicit shared_count( std::auto_ptr<Y> & r )
這其中只有shared_count沒有對pi_進行內存分配，其它都分配了，而它們的參數均是直接由shared_ptr直接傳遞進來的。而默認構造shared_ptr的時候，shared_count亦使用默認構造。下面是shared_ptr的數據成員：
T * px; // contained pointer
boost::detail::shared_count pn; // reference counter
下面的代碼證明了我所說的構造方式：
shared_ptr(): px(0), pn() // never throws in 1.30+
{
}
template<class Y>
explicit shared_ptr( Y * p ): px( p ), pn( p ) // Y must be complete
{
boost::detail::sp_enable_shared_from_this( pn, p, p );
}
//
// Requirements: D's copy constructor must not throw
//
// shared_ptr will release p by calling d(p)
//
template<class Y, class D> shared_ptr(Y * p, D d): px(p), pn(p, d)
{
boost::detail::sp_enable_shared_from_this( pn, p, p );
}
// As above, but with allocator. A's copy constructor shall not throw.
template<class Y, class D, class A> shared_ptr( Y * p, D d, A a ): px( p ), pn( p, d, a )
{
boost::detail::sp_enable_shared_from_this( pn, p, p );
}
上面這些代碼證明了一點，在沒有發生拷貝構造和賦值的前提下，只有當使用默認構造的shared_ptr才等價，其它情況都不等價，哪怕T * px;的這個px相等，因為它跟等價比較沒有任何關系。同時通過源碼分析我們也可以發現一個奇怪的現象，即：
如果使用的是默認構造，那么即便是shared_ptr的類型不同，那么它們也會等價。而對于相等判斷來說，這會導致一個編譯錯誤。
當然，你明白原理了就不奇怪了，因為你所比較的對象是類型無關的。下面的代碼將證明我所說的：
#include <iostream>
#include <boost/tr1/memory.hpp>
using namespace std;
using namespace std::tr1;
#define PrintExp( exp ) \
cout<< boolalpha << "( " << # exp << " ) = " << (exp) << endl
template <class Ty1, class Ty2>
inline bool equiv(shared_ptr<Ty1> left,
shared_ptr<Ty2> right)
{
return !(left < right) && !(right < left);
}
int main()
{
shared_ptr<int> sp1( new int(100) );
shared_ptr<int> sp2;
PrintExp( equiv( sp1, sp2 ) );
shared_ptr<double> sp3;
PrintExp( equiv( sp2, sp3 ) );
shared_ptr<int> sp4;
PrintExp( equiv( sp2, sp4 ) );
shared_ptr<int> sp5( (int*)NULL );
PrintExp( equiv( sp4, sp5 ) );
return 0;
}
等價還有另外一種情況，即通過拷貝構造或者賦值，下面的代碼清楚的說明了為什么這些情況下，我們的pi_會相等最終導致判別式!(left < right) && !(right < left)為真：
shared_count(shared_count const & r): pi_(r.pi_) // nothrow
#if defined(BOOST_SP_ENABLE_DEBUG_HOOKS)
, id_(shared_count_id)
#endif
{
if( pi_ != 0 ) pi_->add_ref_copy();
}
// throws bad_weak_ptr when r.use_count() == 0
explicit shared_count(weak_count const & r);
// constructs an empty *this when r.use_count() == 0
shared_count( weak_count const & r, sp_nothrow_tag );
shared_count & operator= (shared_count const & r) // nothrow
{
sp_counted_base * tmp = r.pi_;
if( tmp != pi_ )
{
if( tmp != 0 ) tmp->add_ref_copy();
if( pi_ != 0 ) pi_->release();
pi_ = tmp;
} // 如果這里還有個else的話，那么就意味著pi_=tmp，因為tmp=r.pi_，則pi_=r.pi_。
// 那么pi_=tmp;這個賦值動作有
// 沒有又有什么關系呢？
return *this;
}
到這里我想我們對此應該形成了一個比較清楚的概念了吧，呵呵。由于!(left < right) && !(right < left)的支持，使得shared_ptr可以作為容器的Key，比如說set、map等。另外補充一下就是weak_ptr也有類似的行為。
下面再附上一篇，這選自《Effective STL》的條款19，對我們理解這些很有幫助。
條款19：了解相等和等價的區別
STL充滿了比較對象是否有同樣的值。比如，當你用find來定位區間中第一個有特定值的對象的位置，find必須可以比較兩個對象，看看一個的值是否與另一個相等。同樣，當你嘗試向set中插入一個新元素時，set::insert必須可以判斷那個元素的值是否已經在set中了。
find算法和set的insert成員函數是很多必須判斷兩個值是否相同的函數的代表。但它們以不同的方式完成，find對“相同”的定義是相等，基于operator==。set::insert對“相同”的定義是等價，通常基于operator<。因為有定義不同，所以有可能一個定義規定了兩個對象有相同的值而另一個定義判定它們沒有。結果，如果你想有效使用STL，那么你必須明白相等和等價的區別。
操作上來說，相等的概念是基于operator==的。如果表達式“x == y”返回true，x和y有相等的值，否則它們沒有。這很直截了當，但要牢牢記住，因為x和y有相等的值并不意味著所有它們的成員有相等的值。比如，我們可能有一個內部記錄了最后一次訪問的Widget類。
class Widget {
public:
...
private:
TimeStamp lastAccessed;
...
};
我們可以有一個用于Widget的忽略這個域的operator==：
bool operator==(const Widget& lhs, const Widget& rhs) {
// 忽略lastAccessed域的代碼
}
在這里，兩個Widget即使它們的lastAccessed域不同也可以有相等的值。
等價是基于在一個有序區間中對象值的相對位置。等價一般在每種標準關聯容器（比如，set、multiset、map和multimap）的一部分——排序順序方面有意義。兩個對象x和y如果在關聯容器c的排序順序中沒有哪個排在另一個之前，那么它們關于c使用的排序順序有等價的值。這聽起來很復雜，但實際上，它不。考慮一下，舉一個例子，一個set<Widget> s。兩個Widget w1和w2，如果在s的排序順序中沒有哪個在另一個之前，那么關于s它們有等價的值。set<Widget>的默認比較函數是less<Widget>，而默認的less<Widget>簡單地對Widget調用operator<，所以w1和w2關于operator<有等價的值如果下面表達式為真：
!(w1 < w2) // w1 < w2時它非真
&& // 而且
!(w2<w1) // w2 < w1時它非真
這個有意義：兩個值如果沒有哪個在另一個之前（關于某個排序標準），那么它們等價（按照那個標準）。
在一般情況下，用于關聯容器的比較函數不是operator<或甚至less，它是用戶定義的判斷式。（關于判斷式的更多信息參見條款39。）每個標準關聯容器通過它的key_comp成員函數來訪問排序判斷式，所以如果下式求值為真，兩個對象x和y關于一個關聯容器c的排序標準有等價的值：
!c.key_comp()(x, y) && !c.key_comp()(y, x) // 在c的排序順序中
// 如果x在y之前它非真，
// 同時在c的排序順序中
// 如果y在x之前它非真
表達式!c.key_comp()(x, y)看起來很丑陋，但一旦你知道c.key_comp()返回一個函數（或一個函數對象），丑陋就消散了。!c.key_comp()(x, y)只不過是調用key_comp返回的函數（或函數對象），并把x和y作為實參。然后對結果取反，c.key_comp()(x, y)僅當在c的排序順序中x在y之前時返回真，所以!c.key_comp()(x, y)僅當在c的排序順序中x不在y之前時為真。
要完全領會相等和等價的含義，考慮一個忽略大小寫的set<string>，也就是set的比較函數忽略字符串中字符大小寫的set<string>。這樣的比較函數會認為“STL”和“stL”是等價的。條款35演示了怎么實現一個函數，ciStringCompare，它進行了忽略大小寫比較，但set要一個比較函數的類型，不是真的函數。要天平這個鴻溝，我們寫一個operator()調用了ciStringCompare的仿函數類：
struct CIStringCompare: // 用于忽略大小寫
public // 字符串比較的類；
binary_function<string, string, bool> { // 關于這個基類的信息
// 參見條款40
bool operator()(const string& lhs,
const string& rhs) const
{
return ciStringCompare(lhs, rhs); // 關于ciStringCompare
} // 是怎么實現的參見條款35
}
給定CIStringCompare，要建立一個忽略大小寫的set<string>就很簡單了：
set<string, CIStringCompare> ciss; // ciss = “case-insensitive
// string set”
如果我們向這個set中插入“Persephone”和“persephone”，只有第一個字符串加入了，因為第二個等價于第一個：
ciss.insert("Persephone"); // 一個新元素添加到set中
ciss.insert("persephone"); // 沒有新元素添加到set中如果我們現在使用set的find成員函數搜索字符串“persephone”，搜索會成功，
if (ciss.find("persephone") != ciss.end())... // 這個測試會成功但如果我們用非成員的find算法，搜索會失敗：
if (find(ciss.begin(), ciss.end(),
"persephone") != ciss.end())... // 這個測試會失敗那是因為“persephone”等價于“Persephone”（關于比較仿函數CIStringCompare），但不等于它（因為string("persephone") != string("Persephone")）。這個例子演示了為什么你應該跟隨條款44的建議優先選擇成員函數（就像set::find）而不是非成員兄弟（就像find）的一個理由。
你可能會奇怪為什么標準關聯容器是基于等價而不是相等。畢竟，大多數程序員對相等有感覺而缺乏等價的感覺。（如果不是這樣，那就不需要本條款了。）答案乍看起來很簡單，但你看得越近，就會發現越多問題。
標準關聯容器保持有序，所以每個容器必須有一個定義了怎么保持東西有序的比較函數（默認是less）。等價是根據這個比較函數定義的，所以標準關聯容器的用戶只需要為他們要使用的任意容器指定一個比較函數（決定排序順序的那個）。如果關聯容器使用相等來決定兩個對象是否有相同的值，那么每個關聯容器就需要，除了它用于排序的比較函數，還需要一個用于判斷兩個值是否相等的比較函數。（默認的，這個比較函數大概應該是equal_to，但有趣的是equal_to從沒有在STL中用做默認比較函數。當在STL中需要相等時，習慣是簡單地直接調用operator==。比如，這是非成員find算法所作的。）
讓我們假設我們有一個類似set的STL容器叫做set2CF，“set with two comparison functions”。第一個比較函數用來決定set的排序順序，第二個用來決定是否兩個對象有相同的值。現在考慮這個set2CF：
set2CF<string, CIStringCompare, equal_to<string> > s; 在這里，s內部排序它的字符串時不考慮大小寫，等價標準直覺上是這樣：如果兩個字符串中一個等于另一個，那么它們有相同的值。讓我們向s中插入哈迪斯強娶的新娘（Persephone）的兩個拼寫：
s.insert("Persephone");
s.insert("persephone");
著該怎么辦？如果我們說"Persephone" != "persephone"然后兩個都插入s，它們應該是什么順序？記住排序函數不能分別告訴它們。我們可以以任意順序插入，因此放棄以確定的順序遍歷set內容的能力嗎？（不能已確定的順序遍歷關聯容器元素已經折磨著multiset和multimap了，因為標準沒有規定等價的值（對于multiset）或鍵（對于multimap）的相對順序。）或者我們堅持s的內容的一個確定順序并忽略第二次插入的嘗試（“persephone”的那個）? 如果我們那么做，這里會發生什么？
if (s.find("persephone") != s.end())... // 這個測試成功或失敗？大概find使用了等價檢查，但如果我們為了維護s中元素的一個確定順序而忽略了第二個insert的調用，這個find會失敗，即使“persephone”的插入由于它是一個重復的值的原則而被忽略！
總之，通過只使用一個比較函數并使用等價作為兩個值“相等”的意義的仲裁者，標準關聯容器避開了很多會由允許兩個比較函數而引發的困難。一開始行為可能看起來有些奇怪（特別是當你發現成員和非成員find可能返回不同結果），但最后，它避免了會由在標準關聯容器中混用相等和等價造成的混亂。
有趣的是，一旦你離開有序的關聯容器的領域，情況就變了，相等對等價的問題會——已經——重臨了。有兩個基于散列表的非標準（但很常見）關聯容器的一般設計。一個設計是基于相等，而另一個是基于等價。我鼓勵你轉到條款25去學更多這樣的容器和設計以決定該用哪個。