shared_ptr学习

成员函数
template <class Y> explicit shared_ptr(Y* p);
这个构造函数获得给定指针p的所有权。参数 p 必须是指向 Y 的有效指针。构造后引用计数设为1。唯一从这个构造函数抛出的异常是std::bad_alloc (仅在一种很罕见的情况下发生，即不能获得引用计数器所需的自由空间)。

template <class Y,class D> shared_ptr(Y* p,D d);
这个构造函数带有两个参数。第一个是shared_ptr将要获得所有权的那个资源，第二个是shared_ptr被销毁时负责释放资源的一个对象，被保存的资源将以d(p)的形式传给那个对象。因此p的值是否有效取决于d。如果引用计数器不能分配成功，shared_ptr抛出一个类型为std::bad_alloc的异常。

shared_ptr(const shared_ptr& r);
r中保存的资源被新构造的shared_ptr所共享，引用计数加一。这个构造函数不会抛出异常。

template <class Y> explicit shared_ptr(const weak_ptr<Y>& r);
从一个weak_ptr构造shared_ptr。这使得weak_ptr的使用具有线程安全性，因为指向weak_ptr参数的共享资源的引用计数将会自增(weak_ptr不影响共享资源的引用计数)。如果weak_ptr为空 (r.use_count()==0), shared_ptr 抛出一个类型为bad_weak_ptr的异常。

template <typename Y> shared_ptr(std::auto_ptr<Y>& r);
这个构造函数从一个auto_ptr获取r中保存的指针的所有权，方法是保存指针的一份拷贝并对auto_ptr调用release。构造后的引用计数为1。而r当然就变为空的。如果引用计数器不能分配成功，则抛出 std::bad_alloc 。

~shared_ptr();
shared_ptr析构函数对引用计数减一。如果计数为零，则保存的指针被删除。删除指针的方法是调用operator delete 或者，如果给定了一个执行删除操作的客户化删除器对象，就把保存的指针作为唯一参数调用这个对象。析构函数不会抛出异常。

shared_ptr& operator=(const shared_ptr& r); 
赋值操作共享r中的资源，并停止对原有资源的共享。赋值操作不会抛出异常。

void reset();
reset函数用于停止对保存指针的所有权的共享。共享资源的引用计数减一。

T& operator*() const;
这个操作符返回对已存指针所指向的对象的一个引用。如果指针为空，调用operator* 会导致未定义行为。这个操作符不会抛出异常。

T* operator->() const;
这个操作符返回保存的指针。这个操作符与operator*一起使得智能指针看起来象普通指针。这个操作符不会抛出异常。

T* get() const;
get函数是当保存的指针有可能为空时(这时 operator* 和 operator-> 都会导致未定义行为)获取它的最好办法。注意，你也可以使用隐式布尔类型转换来测试 shared_ptr 是否包含有效指针。这个函数不会抛出异常。

bool unique() const;
这个函数在shared_ptr是它所保存指针的唯一拥有者时返回 true ；否则返回 false。 unique 不会抛出异常。

long use_count() const;
use_count 函数返回指针的引用计数。它在调试的时候特别有用，因为它可以在程序执行的关键点获得引用计数的快照。小心地使用它，因为在某些可能的shared_ptr实现中，计算引用计数可能是昂贵的，甚至是不行的。这个函数不会抛出异常。

operator unspecified-bool-type() const;
这是个到unspecified-bool-type类型的隐式转换函数，它可以在Boolean上下文中测试一个智能指针。如果shared_ptr保存着一个有效的指针，返回值为True；否则为false。注意，转换函数返回的类型是不确定的。把返回类型当成bool用会导致一些荒谬的操作，所以典型的实现采用了safe bool idiom，它很好地确保了只有可适用的Boolean测试可以使用。这个函数不会抛出异常。

void swap(shared_ptr<T>& b);
这可以很方便地交换两个shared_ptr。swap 函数交换保存的指针(以及它们的引用计数)。这个函数不会抛出异常。

普通函数
template <typename T,typename U>
  shared_ptr<T> static_pointer_cast(const shared_ptr<U>& r);
要对保存在shared_ptr里的指针执行static_cast，我们可以取出指针然后强制转换它，但我们不能把它存到另一个shared_ptr里；新的 shared_ptr 会认为它是第一个管理这些资源的。解决的方法是用 static_pointer_cast. 使用这个函数可以确保被指物的引用计数保持正确。static_pointer_cast 不会抛出异常。

用法
使用shared_ptr解决的主要问题是知道删除一个被多个客户共享的资源的正确时机。下面是一个简单易懂的例子，有两个类 A 和 B, 它们共享一个int实例。使用 boost::shared_ptr, 你需要必须包含 "boost/shared_ptr.hpp".

#include "boost/shared_ptr.hpp"
#include <cassert>
class A {
  boost::shared_ptr<int> no_;
public:
  A(boost::shared_ptr<int> no) : no_(no) {}
  void value(int i) {
    *no_=i;
  }
};
class B {
  boost::shared_ptr<int> no_;
public:
  B(boost::shared_ptr<int> no) : no_(no) {}
  int value() const {
    return *no_;
  }
};
int main() {
    boost::shared_ptr<int> temp(new int(14));
    A a(temp);
    B b(temp);
    a.value(28);
    assert(b.value()==28);
}

类 A 和 B都保存了一个 shared_ptr<int>. 在创建 A 和 B的实例时，shared_ptr temp 被传送到它们的构造函数。这意味着共有三个 shared_ptr：a, b, 和 temp，它们都引向同一个int实例。如果我们用指针来实现对一个的共享，A 和 B 必须能够在某个时间指出这个int要被删除。在这个例子中，直到main的结束，引用计数为3，当所有 shared_ptr离开了作用域，计数将达到0，而最后一个智能指针将负责删除共享的 int.

shared_ptr 与标准库容器
把对象直接存入容器中有时会有些麻烦。以值的方式保存对象意味着使用者将获得容器中的元素的拷贝，对于那些复制是一种昂贵的操作的类型来说可能会有性能的问题。此外，有些容器，特别是 std::vector, 当你加入元素时可能会复制所有元素，这更加重了性能的问题。最后，传值的语义意味着没有多态的行为。如果你需要在容器中存放多态的对象而且你不想切割它们，你必须用指针。如果你用裸指针，维护元素的完整性会非常复杂。从容器中删除元素时，你必须知道容器的使用者是否还在引用那些要删除的元素，不用担心多个使用者使用同一个元素。这些问题都可以用shared_ptr来解决。

下面是如何把共享指针存入标准库容器的例子。

#include <boost/shared_ptr.hpp>
#include <vector>
#include <iostream>
class A {
public:
  virtual void sing()=0;
protected:
  virtual ~A() {};
};
class B : public A {
public:
  virtual void sing() {
    std::cout << "Do re mi fa so la";
  }
};
boost::shared_ptr<A> createA() {
  boost::shared_ptr<A> p(new B());
  return p;
}
int main() {
  typedef std::vector<boost::shared_ptr<A> > container_type;
  typedef container_type::iterator iterator;
  container_type container;
  for (int i=0;i<10;++i) {
    container.push_back(createA());
  }
  std::cout << "The choir is gathered: /n";
  iterator end=container.end();
  for (iterator it=container.begin();it!=end;++it) {
    (*it)->sing();
  }
}

这里有两个类, A 和 B, 各有一个虚拟成员函数 sing. B 从 A公有继承而来，并且如你所见，工厂函数 createA 返回一个动态分配的B的实例，包装在shared_ptr<A>里。在 main里, 一个包含shared_ptr<A>的 std::vector 被放入10个元素，最后对每个元素调用sing。如果我们用裸指针作为元素，那些对象需要被手工删除。而在这个例子里，删除是自动的，因为在vector的生存期中，每个shared_ptr的引用计数都保持为1；当 vector 被销毁，所有引用计数器都将变为零，所有对象都被删除。有趣的是，即使 A 的析构函数没有声明为 virtual, shared_ptr 也会正确调用 B的析构函数！

上面的例子示范了一个强有力的技术，它 涉及A里面的protected析构函数。因为函数 createA 返回的是 shared_ptr<A>, 因此不可能对shared_ptr::get返回的指针调用 delete 。这意味着如果为了向某个需要裸指针的函数传送裸指针而从shared_ptr中取出裸指针的话，它不会由于意外地被删除而导致灾难。那么，又是如何允许 shared_ptr 删除它的对象的呢？ 这是因为指针指向的真正类型是 B; 而B的析构函数不是protected的。这是非常有用的方法，用于给shared_ptr中的对象增加额外的安全性。

shared_ptr的 定制删除器
有时你会发现你要把shared_ptr用于某个特别的类型，它需要其它清除操作而不是简单的 delete. shared_ptr可以通过客户化删除器来支持这种需要。那些处理象 FILE*这样的操作系统句柄的资源通常要使用象fclose这样的操作来释放。要在shared_ptr里使用 FILE* ，我们要定义一个类来负责释放相应的资源。

class FileCloser {
public:
   void operator()(FILE* file) {
    std::cout << "The FileCloser has been called with a FILE*, "
      "which will now be closed./n";
    if (file!=0)
      fclose(file);
  }
};

这是一个函数对象，我们用它来确保在资源要释放时调用 fclose 。下面是使用FileCloser类的示例程序。

int main() {
  std::cout <<
    "shared_ptr example with a custom deallocator./n";
  {
    FILE* f=fopen("test.txt","r");
    if (f==0) {
      std::cout << "Unable to open file/n";
      throw "Unable to open file";
    }
    boost::shared_ptr<FILE>  my_shared_file(f, FileCloser());
    // 定位文件指针
    fseek(my_shared_file.get(),42,SEEK_SET);
  }
  std::cout << "By now, the FILE has been closed!/n";
}

注意，在访问资源时，我们需要对 shared_ptr使用 &* 、 get 或 get_pointer。(请注意最好使用 &*. 另两个选择不太清晰) 这个例子还可以更简单，如果我们在释放资源时只需要调用一个单参数函数的话，就根本不需要创建一个客户化删除器类型。上面的例子可以重写如下：

{
  FILE* f=fopen("test.txt","r");
  if (f==0) {
    std::cout << "Unable to open file/n";
    throw file_exception();
  }
  boost::shared_ptr<FILE> my_shared_file(f,&fclose);
  // 定位文件指针
  fseek(&*my_shared_file,42,SEEK_SET);
}
std::cout << "By now, the FILE* has been closed!/n";

定制删除器在处理需要特殊释放程序的资源时非常有用。由于删除器不是 shared_ptr 类型的一部分，所以使用者不需要知道关于智能指针所拥有的资源的任何信息(当然除了如何使用它！)。例如，你可以使用对象池，定制删除器只需简单地把对象返还到池中。或者，一个 singleton 对象应该使用一个什么都不做的删除器。

我们已经看到对基类使用 protected 析构函数有助于增加使用shared_ptr的类的安全性。另一个达到同样安全级别的方法是， 声明析构函数为 protected (或 private) 并使用一个定制删除器来负责销毁对象。这个定制删除器必须是它要删除的类的友元，这样它才可以工作。封装这个删除器的好方法是把它实现为私有的嵌套类，如下例所示：

#include <boost/shared_ptr.hpp>
#include <iostream>
class A {
  class deleter {
    public:
      void operator()(A* p) {
        delete p;
      }
  };
  friend class deleter;
public:
  virtual void sing() {
    std::cout << "Lalalalalalalalalalala";
  }
  static boost::shared_ptr<A> createA() {
    boost::shared_ptr<A> p(new A(),A::deleter());
    return p;
  }
protected:
  virtual ~A() {};
};
int main() {
  boost::shared_ptr<A> p=A::createA();
}

注意，我们在这里不能使用普通函数来作为 shared_ptr<A> 的工厂函数，因为嵌套的删除器是A私有的。使用这个方法，用户不可能在栈上创建 A的对象，也不可能对A的指针调用 delete 。

从this创建shared_ptr 
有时候，需要从this获得 shared_ptr ，即是说，你希望你的类被shared_ptr所管理，你需要把"自身"转换为shared_ptr的方法。看起来不可能？好的，解决方案来自于我们即将讨论的另一个智能指针boost::weak_ptr. weak_ptr 是 shared_ptr的一个观察者；它只是安静地坐着并看着它们，但不会影响引用计数。通过存储一个指向this的 weak_ptr 作为类的成员，就可以在需要的时候获得一个指向this的 shared_ptr。为了你可以不必编写代码来保存一个指向this的 weak_ptr，接着又从weak_ptr获shared_ptr得，Boost.Smart_ptr 为这个任务提供了一个助手类，称为 enable_shared_from_this. 只要简单地让你的类公有地派生自 enable_shared_from_this，然后在需要访问管理this的shared_ptr时，使用函数 shared_from_this 就行了。下面的例子示范了如何使用 enable_shared_from_this ：

#include "boost/shared_ptr.hpp"
#include "boost/enable_shared_from_this.hpp"
class A;
void do_stuff(boost::shared_ptr<A> p) {
  ...
}
class A : public boost::enable_shared_from_this<A> {
public:
  void call_do_stuff() {
    do_stuff(shared_from_this());
  }
};
int main() {
  boost::shared_ptr<A> p(new A());
  p->call_do_stuff();
}

这个例子还示范了你要用shared_ptr管理this的情形。类 A 有一个成员函数 call_do_stuff 需要调用一个普通函数 do_stuff, 这个普通函数需要一个类型为 boost:: shared_ptr<A>的参数。现在，在 A::call_do_stuff里, this 不过是一个 A指针, 但由于 A 派生自 enable_shared_from_this, 调用 shared_from_this 将返回我们所要的 shared_ptr 。 在enable_shared_from_this的成员函数 shared_from_this里，内部存储的 weak_ptr 被转换为 shared_ptr, 从而增加了相应的引用计数，以确保相应的对象不会被删除。

总结
引用计数智能指针是非常重要的工具。Boost的 shared_ptr 提供了坚固而灵活的解决方案，它已被广泛用于多种环境下。需要在使用者之间共享对象是常见的，而且通常没有办法通知使用者何时删除对象是安全的。shared_ptr 让使用者无需知道也在使用共享对象的其它对象，并让它们无需担心在没有对象引用时的资源释放。这对于Boost的智能指针类而言是最重要的。你会看到Boost.Smart_ptr中还有其它的智能指针，但这一个肯定是你最想要的。通过使用定制删除器，几乎所有资源类型都可以存入 shared_ptr。这使得shared_ptr 成为处理资源管理的通用类，而不仅仅是处理动态分配对象。与裸指针相比，shared_ptr会有一点点额外的空间代价。我还没有发现由于这些代价太大而需要另外寻找一个解决方案的情形。不要去创建你自己的引用计数智能指针类。没有比使用 shared_ptr智能指针更好的了。

使用 shared_ptr场景

1. 当有多个使用者使用同一个对象，而没有一个明显的拥有者时
2. 当要把指针存入标准库容器时
3. 当要传送对象到库或从库获取对象，而没有明确的所有权时
4. 当管理一些需要特殊清除方式的资源时（通过定制删除器的帮助）

shared_ptr陷阱

条款1： 不要把一个原生指针给多个shared_ptr管理

int* ptr = new int;
shared_ptr<int> p1(ptr);
shared_ptr<int> p2(ptr); //logic error
ptr对象被删除了2次，这种问题比喻成“二龙治水”，在原生指针中也同样可能发生。

条款2： 不要把this指针给shared_ptr
class Test{
public:
    void Do(){  m_sp =  shared_ptr<Test>(this);  }
private:
    shared_ptr<Test> m_member_sp;
};
Test* t = new Test;
shared_ptr<Test> local_sp(t);
p->Do();
t对象给了local_sp管理，然后在m_sp =  shared_ptr<Test>(this)这句里又请了一尊神来管理t。这就发生了条款1里“二龙治水”错误。

条款3： shared_ptr作为被保护的对象的成员时，小心因循环引用造成无法释放资源

对象需要相互协作，对象A需要知道对象B的地址，这样才能给对象B发消息（或调用其方法）。设计模式中有大量例子，一个对象中有其他对象的指针。现在把原生指针替换为shared_ptr.

假设a对象中含有一个shared_ptr<B>指向b对象；假设b对象中含有一个shared_ptr<A>指向a对象并且a，b对象都是堆中分配的。考虑某个shared_ptr<A> local_a;是我们能最后一个看到a对象的共享智能指针，其use_count==2,因为对象b中持有a的指针。所以当local_a说再见时，local_a只是把a对象的use_count改成1。同理b对象。然后我们再也看不到a,b的影子了，他们就静静的躺在堆里，成为断线的风筝。
解决方案是：Use weak_ptr to "break cycles."（boost文档里写的）或者显示的清理。

条款4： 不要在函数实参里创建shared_ptr
function ( shared_ptr<int>(new int), g( ) );  //有缺陷
可能的过程是先new int，然后调g( )，g( )发生异常，shared_ptr<int>没有创建，int内存泄露

shared_ptr<int> p(new int());
f(p, g());  //Boost推荐写法

条款5： 对象内部生成shared_ptr
不能把this指针直接扔给shared_ptr. 但是没有禁止在对象内部生成自己的shared_ptr
//这是Boost的例子改的。
class Y: public boost::enable_shared_from_this<Y>
{
    boost::shared_ptr<Y> GetSelf()
    {
        return shared_from_this();
    }
};
普通的（没有继承enable_shared_from_this）类T的shared_ptr<T> p(new T)，p作为栈对象占8个字节，为了记录（new T）对象的引用计数，p会在堆上分配16个字节以保存引用计数等“智能信息”。share_ptr没有“嵌入(intrusive)”到T对象，或者说T对象对share_ptr毫不知情。Y对象则不同，Y对象已经被“嵌入”了一些share_ptr相关的信息，目的是为了找到“全局性”的那16字节的本对象的“智能信息”。原理说完了，就是陷阱：
Y y;
boost::shared_ptr<Y> p=  y.GetSelf(); //无知的代码，y根本就不是new出来的

Y* y = new Y;
boost::shared_ptr<Y> p=  y->GetSelf(); //似是而非，仍旧程序崩盘。
Boost文档说， 在调用shared_from_this()之前，必须存在一个正常途径创建的shared_ptr

boost::shared_ptr<Y> spy(new Y)
boost::shared_ptr<Y> p =  spy->GetSelf(); //OK

条款6 ： 处理不是new的对象要小心
int* pi = (int*)malloc(4)
shared_ptr<int> sp( pi ) ; //delete马嘴不对malloc驴头。

条款7： 多线程对引用计数的影响
如果是轻量级的锁，比如InterLockIncrement等，对程序影响不大；如果是重量级的锁，就要考虑因为share_ptr维护引用计数而造成的上下文切换开销。1.33版本以后的shared_ptr对引用计数的操作使用的是Lock-Free（类似InterLockIncrement函数族）的操作，应该效率不错，而且能保证线程安全（库必须保证其安全，程序员都没有干预这些隐藏事物的机会）。 Boost文档说read，write同时对shared_ptr操作时，行为不确定。这是因为shared_ptr本身有两个成员px，pi。多线程同时对px读写是要出问题的。与一个int的全局变量多线程读写会出问题的原因一样。

条款8： 对象数组用shared_array
int* pint = new int[100];
shared_array<int> p (pint );
既然shared_ptr对应着delete；显然需要一个delete[]对应物shared_array

条款9： 学会用删除器
struct Test_Deleter
{  
    void  operator ()( Test* p){   ::free(p);   }
};
Test* t = (Test*)malloc(sizeof(Test));
new (t) Test;
shared_ptr<Test> sp( t ,  Test_Deleter() ); //删除器可以改变share_ptr销毁对象行为
有了删除器，shared_array无用武之地了。
template<class T>
struct Array_Deleter
{  
    void  operator ()( T*){   delete[] p;   }
};
int* pint = new int[100];
shared_ptr<int> p (pint, Array_Deleter<int>() );

条款10： 学会用分配器
存放引用计数的地方是堆内存，需要16-20字节的开销。如果大量使用shared_ptr会造成大量内存碎片。shared_ptr构造函数的第3个参数是分配器，可以解决这个问题。
shared_ptr<Test> p( (new Test), Test_Deleter(), Mallocator<Test>() );
注意删除器Test_Deleter是针对Test类的。分配器是针对shared_ptr内部数据的；Mallocator<Test>()是个临时对象（无状态的），符合STL分配器规约。
template <typename T>
class Mallocator {
    //。。。。。。
    T * allocate(const size_t n) const {
        return singleton_pool<T,sizeof(T)>::malloc();
    }
    //。。。。。。
Mallocator传入Test，实际分配的类型却是
class boost::detail::sp_counted_impl_pda<class Test *,
                                         struct Test_Deleter,
                                         class Mallocator<class Test> >
这是用typeid(T).name()打印出来的，可能和rebind相关。

条款11  weak_ptr在使用前需要检查合法性
weak_ptr<K> wp;
{
shared_ptr<K>  sp(new K);  //sp.use_count()==1
wp = sp; //wp不会改变引用计数，所以sp.use_count()==1
shared_ptr<K> sp_ok = wp.lock(); //wp没有重载->操作符，只能这样取所指向的对象
}
shared_ptr<K> sp_null = wp.lock(); //sp_null .use_count()==0;
因为上述代码中sp和sp_ok离开了作用域，其容纳的K对象已经被释放了，得到了一个容纳NULL指针的sp_null对象；在使用wp前需要调用wp.expired()函数判断一下。因为wp仍旧存在，虽然引用计数等于0，仍有某处“全局”性的存储块保存着这个计数信息。直到最后一个weak_ptr对象被析构，这块“堆”存储块才能被回收。否则weak_ptr无法知道自己所容纳的那个指针资源的当前状态。

条款12  不要new shared_ptr<T>
本来shared_ptr就是为了管理指针资源的，不要又引入一个需要管理的指针资源shared_ptr<T>*

条款13   尽量不要get
class B{...};
class D : public B{ ...};  //继承层次关系
shared_ptr<B> sp (new D);    //通过隐式转换，储存D的指针。
B* b = sp.get();             //shared_ptr辛辛苦苦隐藏的原生指针就这么被刨出来了。
D* d = dynamic_cast<D*>(b);  //这是使用get的正当理由吗？
正确的做法
shared_ptr<B> spb (new D)  ;
shared_ptr<D> spd =  shared_dynamic_cast<D>(spb); //变成子类的指针
shared_ptr在竭尽全力表演的像一个原生指针，原生指针能干的事，它也基本上能干。

另一个同get相关的错误
shared_ptr<T> sp(new T);
shared_ptr<T> sp2( sp.get() ) ;//又一个“二龙治水”实例，指针会删2次而错误。

条款14  不要memcpy shared_ptr
shared_ptr<B> sp1 (new B)  ;
shared_ptr<B> sp2;
memcpy(&sp2,&sp1,sizeof(shared_ptr<B>)); //sp2.use_count()==1
很显然，不是通过正常途径（拷贝构造，赋值运算），引用计数是不会正确增长的。

条款15  使用BOOST预定义的宏去改变shared_ptr行为
shared_ptr行为由类似BOOST_SP_DISABLE_THREADS这样的宏控制。需要去学习他们到底是干什么的。大师Andrei Alexandrescu设计了一种基于模板策略设计模式的智能指针，通过几个模板参数去定制化智能指针的行为。Boost却不以为然，官方解释是：需要统一的接口，这样利于大规模书写。smart_ptr<T,OwnershipPolicy,ConversionPolicy,CheckingPolicy,StoragePolicy> sp(new T);上述接口缺点是外形复杂，看上去像个大花脸。优点是客户程序员可以轻易的定制行为。

条款16  构造函数里调用shared_from_this会抛出异常
class Holder:public enable_shared_from_this<Holder>{
public:
    Holder() {
        shared_ptr<Holder> sp = shared_from_this();
        int x = sp.use_count();
    }
};
同前面条款5，不符合enable_shared_from_this使用前提。

shared_array

shared_array 用于共享数组所有权的智能指针。它与shared_ptr的关系就如scoped_array与scoped_ptr的关系。shared_array 与 shared_ptr 的不同之处主要在于它是用于数组的而不是用于单个对象的。在我们讨论 scoped_array时，我提到过通常std::vector是一个更好的选择。但 shared_array 比 vector更有价值，因为它提供了对数组所有权的共享。shared_array 的接口与 shared_ptr非常相似，差别仅在于增加了一个下标操作符，以及不支持定制删除器。

由于一个指向std::vector的shared_ptr提供了比shared_array更多的灵活性，所以我们就不对shared_array的用法进行讨论了。