2.基本功能

“柔弱的”weak_ptr专门用来解决上述设计中必须面对的循环指向问题。

weak_ptr并不是真正的智能指针，它必须依附于shared_ptr存在。对应前面的C1、C2，我们写一个弱引用版本的C3和C4的例子：
 

struct C4;
struct C3
{
    ~C3(){cout << "~C3" << endl;}
    weak_ptr <C4> _c4;
};

struct C4
{
    ~C4(){cout << "~C4" << endl;}
    weak_ptr <C3> _c3;
};

void test_weak_reference()
{
    shared_ptr <C3> pc3(make_shared <C3> ());
    shared_ptr <C4> pc4(make_shared <C4> ());

    pc3->_c4 = pc4;
    pc4->_c3 = pc3;

    cout << "c3's ref count = " << pc3.use_count() << endl; // 1
    cout << "c4's ref count = " << pc4.use_count() << endl; // 1
}

019行，将一个shared_ptr，赋值给一个弱指针（weak_ptr），并不会造成shared_ptr的引用计数加1。因此后续输出时的内容才会是两个1。作为对比，将一个shared_ptr赋值给另一个shared_ptr（前例的情况），则会造成引用计数加1。

既然不增加人家的引用计数，弱指针在析构时，当然也不会减少人家的引用计数。为什么说“人家的”呢？

因为引用计数还是由那些shared_ptr在维护。弱指针其实一点也不“弱”，它不负责管理引用计数，却同样可以使用裸指针。

这种设计通常称为“观察者”模式。标准库的设计者，把weak_ptr给“阉割”了。

前面说过，weak_ptr不能算是真正的智能指针，因为它并没有直接模拟裸指针的行为。既不能使用“->”来访问所管理的指针，也不能使用“*”去访问所管理的裸指针所指向的对象。

如果我们希望通过weak_ptr操作裸指针，必须从该裸指针反过来创建一个shared_ptr:

shared_ptr <int> sp1(new int);
weak_ptr <int> wp(sp1); //shared->weak
cout << wp.use_count() << endl;// 1
//    *wp = 10; //不行

shared_ptr <int> sp2(wp);//weak->shared
*sp2 = 10;

也可以通过weak_ptr提供的lock()方法得到一个shared_ptr；

shared_ptr <int> sp3 = wp.lock();
*sp3 = 11;

现在sp3、sp2、sp1有共同指向，引用计数为3，指向的数值是11。

不过，weak_ptr也有可能获取不到有效的裸指针。所有伙伴都退租了，因此从weak_ptr身上得到shared_ptr，有可能是空指针，为安全起见，应事先检查：

weak_ptr <int> wp; //空的弱指针
shared_ptr <int> sp = make_shared <int> (12);
wp = sp;

//故意释放sp
sp.reset();

//shared_ptr <int> sp2 = wp;
//assert(! sp2); //sp2铁定是nullptr

上面第8行，会报错：error: conversion from 'std::weak_ptr<int>' to non-scalar type 'std::shared_ptr<int>' requested|

另一个问题，既然引入弱指针目的是为了解决shared_ptr之间的“循环引用”问题，那我们又从弱指针创建出一个shared_ptr，“循环引用”岂不是又出现了？为此，通常从weak_ptr得到的shared_ptr，都只在一个临时代码内使用，用完就丢。以C3和C4为例，假设为C4增加一个IncC3Value()方法：

#include <iostream>
#include <memory>

using namespace std;

struct C4;
struct C3
{
    ~C3() { cout << "~C3" << endl; }
    weak_ptr<C4> _c4;

// 加一个没用的 int 入参，以告诉编译这是 后置++ (而非前置)
    C3& operator++(int)
    {
        cout << "++\n";
        return *this;
    }
};

struct C4
{
    ~C4() {cout << "~C4" << endl; }
    weak_ptr <C3> _c3;

    void IncC3Value()
    {
// _c3 从弱指针，临时提升为 shared_ptr：然后出了它的临时作用域，
//这个智能指针就消失了（引用计数先加1，马上又减1）;不会对当前的
//C4智能指针的最终析构带来什么影响。
        if (auto p = _c3.lock())
        {
            cout << "p's ref count = " << p.use_count() << endl;
            (*p)++;
        }
    }
};

void test_weak_reference()
{
    shared_ptr<C3> pc3 (make_shared<C3>());
    shared_ptr<C4> pc4(make_shared<C4>());

    // 开始人为制作交叉引用：
    pc3->_c4 = pc4; // pc3 拥有 pc4
    pc4->_c3 = pc3; // pc4 拥有 pc3

    cout << "c3's ref count = " << pc3.use_count() << endl; //1
    cout << "c4's ref count = " << pc4.use_count() << endl; //1

    // 测试上面的函数
    pc4->IncC3Value();
}

int main()
{
    test_weak_reference();
}

30行的 if ()条件中，临时从一个 weak_ptr 升级(lock，加锁后)得到 一个 shared_ptr，然后出于它的临时作用域 （也就是 if { … } 范围 ），这个智能指针就消失了（引用数先加1，马上就又减1）；不会对当前的 C4 智能指针对象的最终析构 带什么影响。

有了weak_ptr帮助躲过循环引用，推荐“shared_ptr一体化”的设计方法，

就是，如果一类对象在创建之后需要在多处使用，特别是跨线程使用，那么应该在创建或声明的地方，就为它绑上shared_ptr。

无需质疑，shared_ptr相比裸指针肯定会带来性能损耗。最直接的，为保证并发环境下引用计数变化的准确性，shared_ptr一定在内部使用了相关锁操作，而这一定会带来性能损耗。

不过这一点点损耗在多数情况下，可以接受，反过来，裸指针内存管理哪怕只是出错一点点，却万万不可接受。

注意，“在创建或声明时就为它绑上shared_ptr”，这话听来简单，不就是在创建对象时，直接使用make_shared吗？不仅如此，实际上还包括各处需要用到该类对象的声明，包括类的成员数据，包括函数入参和返回值等，比如有一个类Coo：

class Coo{...};

如果我们在设计时就认为该类对象应当使用shared_ptr管理，那么首先建议在类中定义智能指针的别名，以方便使用：

class Coo
{
public:
    typedef std::shared_ptr <Coo> Ptr;
    ...
};

有函数的入参或返回值用到它，则:

Coo::Ptr foo(int a, Coo::Ptr pcoo)
{
    ...
}

注意，虽然别名叫做“Ptr”，但其实就智能指针对象而言，这里使用的是传值，会带来复制的成本，包括shared_ptr在复制对象时的必然的操作：加锁，然后让“引用计数”加1，这样做的好处是安全，且foo在使用时，该智能指针永远有效（除非它一开始就无效），如果我们使用引用技术：

void foo_ref(int a, CooPtr& pcoo)
{
    ...
}

那么在函数体中，pcoo不一定一直有效，因为在复杂的并发情况下，foo_ref的调用可能是异步的，调用者可能在foo_ref还没执行完毕就先结束了，从而造成pcoo所引用的shared_ptr失效。

weak_ptr基本不用作函数的入参或返回值（特定目的下除外），它通常用作类成员，以化解循环引用。

但是，并不是说只要是类成员，就一定使用weak_ptr而不使用shared_ptr，恰恰相反，weak_ptr应该只用在可以打破循环的某一环皆可。

比如前例中的C3和C4，更好的设计是其中仅一个使用weak_ptr。

【课堂作业】：只需一环，打破“循环引用”

请重新设计C3或C4类，以便只在其中某个类上使用weak_ptr即可打破循引用。