文档：
http://www.boost.org/doc/libs/1_57_0/libs/smart_ptr/shared_ptr.htm
shared_ptr构造有个原型
template<class Y, class D> shared_ptr(Y * p, D d);d是deleter。如
shared_ptr<FILE> ctx(fp,::flose);
Introduction
The shared_ptr class template stores a pointer to a dynamically allocated object, typically with a C++ new-expression. The object pointed to is guaranteed to be deleted when the last shared_ptr pointing to it is destroyed or reset.
Example:
shared_ptr<X> p1( new X ); shared_ptr<void> p2( new int(5) );
shared_ptr deletes the exact pointer that has been passed at construction time, complete with its original type, regardless of the template parameter. In the second example above, when p2 is destroyed or reset, it will call delete on the original int* that has been passed to the constructor, even though p2 itself is of type shared_ptr<void> and stores a pointer of type void*.
Every shared_ptr meets the CopyConstructible, MoveConstructible, CopyAssignable and MoveAssignable requirements of the C++ Standard Library, and can be used in standard library containers. Comparison operators are supplied so that shared_ptr works with the standard library's associative containers.
Because the implementation uses reference counting, cycles of shared_ptr instances will not be reclaimed. For example, if main() holds a shared_ptr to A, which directly or indirectly holds a shared_ptr back to A, A's use count will be 2. Destruction of the original shared_ptr will leave A dangling with a use count of 1. Use weak_ptr to "break cycles."
The class template is parameterized on T, the type of the object pointed to. shared_ptr and most of its member functions place no requirements on T; it is allowed to be an incomplete type, or void. Member functions that do place additional requirements (constructors, reset) are explicitly documented below.
shared_ptr<T> can be implicitly converted to shared_ptr<U> whenever T* can be implicitly converted to U*. In particular, shared_ptr<T> is implicitly convertible to shared_ptr<T const>, to shared_ptr<U> where U is an accessible base of T, and to shared_ptr<void>.
shared_ptr is now part of the C++11 Standard, as std::shared_ptr.
Starting with Boost release 1.53, shared_ptr can be used to hold a pointer to a dynamically allocated array. This is accomplished by using an array type (T[] or T[N]) as the template parameter. There is almost no difference between using an unsized array, T[], and a sized array, T[N]; the latter just enables operator[] to perform a range check on the index.
Example:
shared_ptr<double[1024]> p1( new double[1024] ); shared_ptr<double[]> p2( new double[n] );
Best Practices
A simple guideline that nearly eliminates the possibility of memory leaks is: always use a named smart pointer variable to hold the result of new. Every occurence of the newkeyword in the code should have the form:
shared_ptr<T> p(new Y);
It is, of course, acceptable to use another smart pointer in place of shared_ptr above; having T and Y be the same type, or passing arguments to Y's constructor is also OK.
If you observe this guideline, it naturally follows that you will have no explicit delete statements; try/catch constructs will be rare.
Avoid using unnamed shared_ptr temporaries to save typing; to see why this is dangerous, consider this example:
void f(shared_ptr<int>, int);
int g();
void ok()
{
shared_ptr<int> p( new int(2) );
f( p, g() );
}
void bad()
{
f( shared_ptr<int>( new int(2) ), g() );
}
The function ok follows the guideline to the letter, whereas bad constructs the temporary shared_ptr in place, admitting the possibility of a memory leak. Since function arguments are evaluated in unspecified order, it is possible for new int(2) to be evaluated first, g() second, and we may never get to the shared_ptrconstructor if g throws an exception. See Herb Sutter's treatment (also here) of the issue for more information.
The exception safety problem described above may also be eliminated by using the make_shared or allocate_shared factory functions defined in boost/make_shared.hpp. These factory functions also provide an efficiency benefit by consolidating allocations.
-------------------------------------------------------------------------------------------------------
boost::scoped_ptr虽然简单易用，但它不能共享所有权的特性却大大限制了其使用范围，而boost::shared_ptr可以解决这一局限。顾名思义，boost::shared_ptr是可以共享所有权的智能指针，首先让我们通过一个例子看看它的基本用法：
#include<iostream> #include<boost/shared_ptr.hpp> using namespace std; using boost::shared_ptr; class A { public: ~A(){ cout<<"destroy ";} void do_sth(){cout<<"do somthing ";} }; int main() { shared_ptr<A> a1(new A()); cout<<"the sample now has "<<a1.use_count()<<" references "; shared_ptr<A> a2=a1; cout<<"the sample now has "<<a1.use_count()<<" references "; a1.reset(); std::cout<<"After Reset sp1. The Sample now has "<<a2.use_count()<<" references "; a2.reset(); std::cout<<"After Reset sp2. "; }
root@iZ23onhpqvwZ:~/ms/boost# ./shared_ptr
the sample now has 1 references
the sample now has 2 references
After Reset sp1. The Sample now has 1 references
destroy
After Reset sp2.
可以看到，boost::shared_ptr指针sp1和sp2同时拥有了implementation对象的访问权限，且当sp1和sp2都释放对该对象的所有权时，其所管理的的对象的内存才被自动释放。在共享对象的访问权限同时，也实现了其内存的自动管理。
boost::shared_ptr的特点：
和前面介绍的boost::scoped_ptr相比，boost::shared_ptr可以共享对象的所有权，因此其使用范围基本上没有什么限制（还是有一些需要遵循的使用规则，下文中介绍），自然也可以使用在stl的容器中。另外它还是线程安全的，这点在多线程程序中也非常重要。
细节：shared_ptr实现了operator bool() const方法来判断一个管理的资源是否被释放。
boost::shared_ptr的使用规则：
boost::shared_ptr并不是绝对安全，下面几条规则能使我们更加安全的使用boost::shared_ptr：
-
避免对shared_ptr所管理的对象的直接内存管理操作，以免造成该对象的重释放
-
shared_ptr并不能对循环引用的对象内存自动管理（这点是其它各种引用计数管理内存方式的通病）。
-
不要构造一个临时的shared_ptr作为函数的参数。
如下列代码则可能导致内存泄漏：
void test()
{
foo(boost::shared_ptr<implementation>(new implementation()),g());
}
正确的用法为：
void test()
{
boost::shared_ptr<implementation> sp (new implementation());
foo(sp,g());
}
当函数g()抛异常的时候就会泄露了，这个是boost文档上特地注明的标准bad Practices。
---------------------
shared_ptr陷阱：
#include<boost/enable_shared_from_this.hpp> #include<boost/make_shared.hpp> #include<iostream> using namespace std; using namespace boost; class A:public enable_shared_from_this<A> { public: A(int n):x(n){} void print(){ cout<<"T:"<<x<<endl;} int x; }; int main() { shared_ptr<A> sp=make_shared<A>(111); sp->print(); shared_ptr<A> p=sp->shared_from_this(); p->x=1000; p->print(); sp->print(); }
注意：千万不能从一个普通对象(非shared_ptr)使用shared_from_this()获去shared_ptr，例如
self_shared ss;
shared_ptr<self_shared> p = ss.shared_from_this();//错误!
在运行时会导致shared_ptr析构时企图删除一个栈上分配的对象，发生未定义行为。
参考：http://blog.csdn.net/mmzsyx/article/details/8090849
enable_shared_from_this原理：http://blog.csdn.net/zhongguoren666/article/details/8618316
C++中没有垃圾回收，所有的内存都要自己管理，也就是说new 与 delete必须由程序员自己去一一对应起来。这个难免会出现这样那样的内存问题。在这种背景下，智能指针应运而生。
智能指针的最终的目的是将一块内存交给一个托管对象，内存何时释放由托管对象来决定，而对对象的访问也使用托管对象来实现。这样子对象new完后就不需要显示的delete了，在它的生命周期结束后（也就是没有托管对象引用它的情况下）就可以自动被释放掉了。
智能指针有些比较简单，如 std::auto_ptr , boost::scope_ptr等等，它们的功能都比较类似，就是在某一个区域内指向一个new出来的对象，当这个指针的生命周期结束后，在析构函数中调用delete函数释放这块内存，这类智能指针充其量就是少写了一个delete而已，由于它不能被传递到该指针生命周期外的其它的地方使用，故没什么太大的用处。
稍微复杂一些的智能指针都是维护是引用记数器的智能指针，这种指针可以任意传递，用法基本上和原生指针类似，所以使用的比较多一些。
带引用记数的智能指针原理上基本类似，就是new了某一个资源的时候，给该资源加上一个计数器，每当有新的智能指针指向这个资源的时候，计数器就加1，当某个指向该资源智能指针超出生命周期或由于其它原因解除了和该资源的引用关系时，计数器减1，当计数器减到0 的时候，表示该资源已经没有指针引用，就可以被释放了。
根据记数器所处的位置不同，基本引用记数器的智能指针又分为两类，一类是计数器处于资源中，一类是记数器处于智能指针中。
引用计数器处于资源中的智能指针管理的资源必须从某一个基类继承下来，在这个基类中提供了addref 与 release方法来管理引用计数。这样子智能指针通过调用资源对象的addref 与 release 方法来实现资源的计数管理。很多类库或系统的框架都会让所有的对象从一个基类中继承，而引用计数功能就可以放在这个基类中实现。这种智能指针是专用的，也就是说它不能管理不从这个基类继承的对象。
另外一种方法是将引用记数器放在智能指针本身中，这样子智能指针就可以管理任意new出来的对象的生命周期，而不会对象本身作任何限制。这类智能指针的基本原理是每当一个智能指针被一个原生指针初始化的时候，就new出来一个引用记数器。当指针被传递的时候，这个引用记数器中的值被修改，而引用记数器本身的地址也被传递给其它的智能指针，这种技术的关键在于，智能指针中保存的不同引用计数器本身，而是引用计数器的一个地址，这样就可以实现同一个资源的多个智能指针的传递过程中能保证引用记数的正确。最后，智能指针引用的对象的释放与引用记数器本身的释放是同步的，即一个资源的引用对象为0的时候，它就可以被删除了，同时，这个引用对象也可以被删除了，因为一个引用对象就是绑定到一个特写资源的，引用对象本身不对重用。这种类型的智能指针代表是boost::share_ptr。
基于引用计数的智能指针一般都会存在循引用的问题，关于循环引用这里兴个例子（代码是网上拷的，见谅）
【1】boost::weak_ptr简介
boost::weak_ptr属于boost库，定义在namespace boost中，包含头文件 #include<boost/weak_ptr.hpp>便可以使用。
【2】boost::weak_ptr详解
智能指针boost::scope_ptr和智能指针boost::shared_ptr就完全可以解决所有单个对象内存的管理问题。
这儿咋还多出一个boost::weak_ptr，是否还有某些案例我们没有考虑到呢？
回答：有。首先 boost::weak_ptr是专门为boost::shared_ptr而准备的。
有时候，我们只关心能否使用对象，并不关心内部的引用计数。
boost::weak_ptr是 boost::shared_ptr的观察者（Observer）对象，观察者？观察者怎么理解呢？
观察者意味着boost::weak_ptr只对boost::shared_ptr进行引用，而不改变其引用计数。
当被观察的boost::shared_ptr失效后，相应的boost::weak_ptr也随之失效。
那么，为什么需要这个观察者呢？那还得从循环引用谈起。
引用计数是一种便利的内存管理机制，但它有一个很大的缺点，那就是不能管理循环引用的对象。
示例代码如下：
#include <string>
#include <iostream>
#include <boost/shared_ptr.hpp>
#include <boost/weak_ptr.hpp>
class parent;
class children;
typedef boost::shared_ptr<parent> parent_ptr;
typedef boost::shared_ptr<children> children_ptr;
class parent
{
public:
~parent() { std::cout <<"destroying parent/n"; }
public:
children_ptr children;
};
class children
{
public:
~children() { std::cout <<"destroying children/n"; }
public:
parent_ptr parent;
};
void test()
{
parent_ptr father(new parent());
children_ptr son(new children);
father->children = son;
son->parent = father;
std::cout<<father.use_count()<<std::endl;//输出2
}
void main()
{
std::cout<<"begin test.../n";
test();
std::cout<<"end test./n";
}
运行该程序可以看到，即使退出了test函数后，由于parent和children对象互相引用，它们的引用计数都是2，不能自动释放，并且此时这两个对象再无法访问到。这就引起了c++中那臭名昭著的内存泄漏。
改成weak_ptr，输出1.
为了解决这种情况，就出现了另一个概念，叫弱引用，弱引用指针从一个强引用指针产生，弱引用不增加被引用对象的引用计数，并提供了相应的函数来判断当前引用的对象是否已经过期被释放。如boost::weak_ptr为是一个指向boost::share_ptr的弱引用。
<1>一般来讲，解除这种循环引用有下面有三种可行的方法：
1. 当只剩下最后一个引用的时候需要手动打破循环引用释放对象。
2. 当parent的生存期超过children的生存期的时候，children改为使用一个普通指针指向parent。
3. 使用弱引用的智能指针打破这种循环引用。
虽然这三种方法都可行，但方法1和方法2都需要程序员手动控制，麻烦且容易出错。
下面主要介绍一下第三种方法和boost中的弱引用的智能指针boost::weak_ptr。
<2>什么是强引用和弱引用？
一个强引用是指当被引用的对象仍活着的话，这个引用也存在（也就是说，只要至少有一个强引用，那么这个对象就不会也不能被释放）。boost::share_ptr就是强引用。
相对而言，弱引用当引用的对象活着的时候不一定存在。仅仅是当它自身存在的时的一个引用。
弱引用并不修改该对象的引用计数，这意味这弱引用它并不对对象的内存进行管理。
在功能上类似于普通指针，然而一个比较大的区别是，弱引用能检测到所管理的对象是否已经被释放，从而避免访问非法内存。
boost::weak_ptr boost::weak_ptr<T>是boost提供的一个弱引用的智能指针，它的声明可以简化如下：
namespace boost { template<typename T> class weak_ptr { public: template <typename Y> weak_ptr(const shared_ptr<Y>& r); weak_ptr(const weak_ptr& r); ~weak_ptr(); T* get() const; bool expired() const; shared_ptr<T> lock() const; }; }
可以看到，boost::weak_ptr必须从一个boost::share_ptr或另一个boost::weak_ptr转换而来，这也说明，进行该对象的内存管理的是那个强引用的boost::share_ptr。
(weak_ptr是为了配合shared_ptr而引入的一种智能指针，它更像是shared_ptr的一个助手而不是智能指针，因为它不具有普通指针的行为，没有重载operator*和->,它的最大作用在于协助shared_ptr工作，像旁观者那样观测资源的使用情况.
)
boost::weak_ptr只是提供了对管理对象的一个访问手段。
boost::weak_ptr除了对所管理对象的基本访问功能（通过get()函数）外，还有两个常用的功能函数：
1. expired() 用于检测所管理的对象是否已经释放；
2. lock() 用于获取所管理的对象的强引用指针。 weak_ptr可以使用一个非常重要的成员函数lock()从被观测的shared_ptr获得一个可用的shared_ptr对象， 从而操作资源。但当expired()==true的时候，lock()函数将返回一个存储空指针的shared_ptr.
<3>通过boost::weak_ptr来打破循环引用
由于弱引用不更改引用计数，类似普通指针，只要把循环引用的一方使用弱引用，即可解除循环引用。
对于上面的那个例子来说，只要把children的定义改为如下方式，即可解除循环引用
class children { public: ~children() { std::cout <<"destroying children "; } public: boost::weak_ptr<parent> parent; };
（还有parent这里变量名和class parent重复，不行，改成parentx就可以了）
【3】boost::weak_ptr总结
虽然通过弱引用指针可以有效的解除循环引用，但这种方式必须在程序员能预见会出现循环引用的情况下才能使用，也可以是说这个仅仅是一种编译期的解决方案。
如果程序在运行过程中出现了循环引用，还是会造成内存泄漏的。
因此，不要认为只要使用了智能指针便能杜绝内存泄漏。
毕竟，对于C++来说，由于没有垃圾回收机制，内存泄漏对每一个程序员来说都是一个非常头痛的问题。
一篇关于weak_ptr小短文：
近期在补充和梳理C++方面的知识的时候，遇到了WeakPtr这个概念和用法，不甚明白，Google出了一堆文字，包括Boost的shared_ptr和weak_ptr的比较，以及其他一些博客里面给的例子以及解释。
其中有一个是这样解释的，原文大意：在C++的weak_ptr里面，有两类指针，一类是拥有对象的生命周期；另一类不拥有，只有访问权。
在这里，我就有点不明白，这两类指针，到底会在编写上面，或者形式上面，有什么区别呢？
或者说weak_ptr到底要解决编程当中的什么问题呢？ 为什么会有这个类型被提出？
经过和一位朋友的讨论，有了答案。
比如现在有两个函数
class A;
void Func1(A* a);
void Func2(A* a);
A* a = new A;
Func1(a);
Func2(a);
他们在同一个作用域的时候，a 被释放后，惯有的操作是 a = NULL这个时候Func2 或者 Func1中都可以判断到这个变化。
但是如果Func1在另外一个线程/进程里面，你在传递过来的时候a并不是空的a，但是指向的对象，已经被释放了，这个指针已经不在有权限去访问了。那么就会出现问题。
所以weak_ptr就出现了，让你在使用资源之前，先去问下HasWeakPtr() 如果有，那么表明这个资源还没有被释放，可以放心去用，否则就应该不能再使用了。
以往的代码，写法： if (a) {}
但是*a 已经被释放之后，其实a并没有在上下文被a = NULL 所以a 还是指向那个地址，但是地址指向的内容已经非法了。
eof
参考：http://www.cnblogs.com/TianFang/archive/2008/09/20/1294590.html
http://blog.csdn.net/mmzsyx/article/details/8090849
std::shared_ptr 和 std::weak_ptr的用法以及引用计数的循环引用问题
在std::shared_ptr被引入之前，C++标准库中实现的用于管理资源的智能指针只有std::auto_ptr一个而已。std::auto_ptr的作用非常有限，因为它存在被管理资源的所有权转移问题。这导致多个std::auto_ptr类型的局部变量不能共享同一个资源，这个问题是非常严重的哦。因为，我个人觉得，智能指针内存管理要解决的根本问题是：一个堆对象（或则资源，比如文件句柄）在被多个对象引用的情况下，何时释放资源的问题。何时释放很简单，就是在最后一个引用它的对象被释放的时候释放它。关键的问题在于无法确定哪个引用它的对象是被最后释放的。std::shared_ptr确定最后一个引用它的对象何时被释放的基本想法是：对被管理的资源进行引用计数，当一个shared_ptr对象要共享这个资源的时候，该资源的引用计数加1，当这个对象生命期结束的时候，再把该引用技术减少1。这样当最后一个引用它的对象被释放的时候，资源的引用计数减少到0，此时释放该资源。下边是一个shared_ptr的用法例子：
- #include <iostream>
- #include <memory>
- class Woman;
- class Man{
- private:
- std::weak_ptr<Woman> _wife;
- //std::shared_ptr<Woman> _wife;
- public:
- void setWife(std::shared_ptr<Woman> woman){
- _wife = woman;
- }
- void doSomthing(){
- if(_wife.lock()){
- }
- }
- ~Man(){
- std::cout << "kill man ";
- }
- };
- class Woman{
- private:
- //std::weak_ptr<Man> _husband;
- std::shared_ptr<Man> _husband;
- public:
- void setHusband(std::shared_ptr<Man> man){
- _husband = man;
- }
- ~Woman(){
- std::cout <<"kill woman ";
- }
- };
- int main(int argc, char** argv){
- std::shared_ptr<Man> m(new Man());
- std::shared_ptr<Woman> w(new Woman());
- if(m && w) {
- m->setWife(w);
- w->setHusband(m);
- }
- return 0;
- }
在Man类内部会引用一个Woman，Woman类内部也引用一个Man。当一个man和一个woman是夫妻的时候，他们直接就存在了相互引用问题。man内部有个用于管理wife生命期的shared_ptr变量，也就是说wife必定是在husband去世之后才能去世。同样的，woman内部也有一个管理husband生命期的shared_ptr变量，也就是说husband必须在wife去世之后才能去世。这就是循环引用存在的问题：husband的生命期由wife的生命期决定，wife的生命期由husband的生命期决定，最后两人都死不掉，违反了自然规律，导致了内存泄漏。
解决std::shared_ptr循环引用问题的钥匙在weak_ptr手上。weak_ptr对象引用资源时不会增加引用计数，但是它能够通过lock()方法来判断它所管理的资源是否被释放。另外很自然地一个问题是：既然weak_ptr不增加资源的引用计数，那么在使用weak_ptr对象的时候，资源被突然释放了怎么办呢？呵呵，答案是你根本不能直接通过weak_ptr来访问资源。那么如何通过weak_ptr来间接访问资源呢？答案是：在需要访问资源的时候weak_ptr为你生成一个shared_ptr，shared_ptr能够保证在shared_ptr没有被释放之前，其所管理的资源是不会被释放的。创建shared_ptr的方法就是lock()方法。
细节：shared_ptr实现了operator bool() const方法来判断一个管理的资源是否被释放。