当前位置 : 主页 > 编程语言 > 其它开发 >

C++ 智能指针浅析

来源:互联网 收集:自由互联 发布时间:2022-06-09
C++ 智能指针浅析 为了解决 C++ 中内存管理这个老大难问题,C++ 11 中提供了三种可用的智能指针。(早期标准库中还存在一种 auto_ptr,但由于设计上的缺陷,已经被 unique_ptr 取代了) 智
C++ 智能指针浅析

为了解决 C++ 中内存管理这个老大难问题,C++ 11 中提供了三种可用的智能指针。(早期标准库中还存在一种 auto_ptr,但由于设计上的缺陷,已经被 unique_ptr 取代了)

智能指针不仅能用来管理动态内存,还能用来管理其他类型的资源,比如互斥锁、数据库连接等,这种用资源管理对象来管理资源的思想被称为 RAII。

原始指针的缺陷
  • 看不出来指向的是对象还是数组,也就不知道该用 delete 还是 delete[]
  • 不知道用完后是否应该销毁,也就是不包含所有权的信息;
  • 不知道该用 delete 还是其他方式释放该对象;
  • double free;
  • dangling pointers(悬空指针),即对象已经被释放了,但指针还指向它。
shared_ptr

shared_ptr 体现的是共享的所有权(shared ownership),通俗地讲,就是这个被管理的对象可以被多个用户使用,只有所有用户都不再需要该资源时,它才可以被释放。

为了实现共享的所有权,shared_ptr 会维护一个引用计数,表示有多少 shared_ptr 指向这个被管理的对象。

简单地来说,当 shared_ptr 被拷贝时(不管是我们主动调用,还是将它作为传值参数或返回值),引用计数就会增加;当 shared_ptr 被析构时(比如离开它的作用域),引用计数就会减少。当引用计数归零时,这个被管理的对象就会被释放。

shared_ptr 中引用计数的操作是原子的,这点和 shared_ptr 的线程安全性有关。

shared_ptr 使用规范

要正确地使用 shared_ptr,需要注意一些问题:

  • 不使用相同的内置指针初始化或 reset 多个 shared_ptr,原因请看后文的 shared_ptr 实现,这样操作会产生多个控制块对象,从而造成 double free;
  • get() 返回的原始指针只应该有一种用途,用来作为参数传递给遗留接口;
    • 不应该 delete get() 返回的指针;
    • 不使用 get() 的返回值去初始化或 reset 另一个智能指针;
    • 当最后一个对应的智能指针被销毁时,get() 返回的指针就无效了;
  • 如果使用智能指针管理资源而不是内存,应当定义自定义删除器;
  • 如果将 shared_ptr 存放到容器中,之后不再需要其中的部分元素,应当调用 erase 将它们删除,不然这些元素的生命周期会被意外地延长。
在单条语句里将 new 来的指针放到智能指针里
int priority();

void processWidget(std::shared_ptr<Widget> pw, int priority);

processWidget(std::shared_ptr<Widget>(new Widget), priority());

该调用事实上由三部分组成:

  1. new Widget
  2. 调用 shared_ptr 构造函数
  3. 调用 priority()

1 应当发生在 2 之前,但标准并没有规定 3 要在何时发生;如果编译器以 1、3、2 这样的顺序来执行,那么如果调用 priority() 时抛出异常,那么就会出现内存泄漏。

如果将程序改为:

std::shared_ptr<Widget> pw(new Widget);

processWidget(pw, priority());

可以强制上面的过程以 1、2、3 的顺序发生,消除了内存泄漏的隐患。

此外,将这里改成 std::move() 效率更高,因为移动不涉及引用计数的增减。

std::shared_ptr<Widget> pw(new Widget);

processWidget(std::move(pw), priority());

避免该内存泄露问题的另一种方法是改用 make_shared()

processWidget(std::make_shared<Widget>(), priority());
make_shared

使用 make_shared() 的优势:

  • 避免上面提到的内存泄露问题;
  • 效率更高:先 new 出内存再传递给 shared_ptr,涉及到两次内存分配,一次分配被管理的对象,一次分配控制块对象;但如果改用 make_shared(),只需要分配一次内存就足够容纳这两个对象。

使用 make_shared() 的缺陷:

  • 不允许指定自定义删除器。
  • 没法用 {} 初始化,make_shared() 将参数完美转发给构造函数时,默认使用 ()
  • 如果类重载了 operator newoperator delete,它的内存分配行为可能表现出特殊的行为;
    • 比如 Widget 类的 operator newoperator delete 可能只处理大小为 sizeof(Widget) 的内存分配;
    • make_shared() 不只是分配对象的动态内存,还会同时分配控制块的内存,这种情况下,就会造成麻烦。
  • 由于控制块和对象放在同一块内存里,引用计数为 0 的时候,对象并不会被释放,只有等到控制块也不再需要的时候,这块内存才会被释放;
    • 只要还有 weak_ptr 指向这个对象,控制块就不会被释放;
    • 对于特别大的对象,这可能是问题。
unique_ptr

unique_ptr 体现的是独占/排他的所有权(exclusive ownership),通俗地讲,就是这个被管理的对象为单个用户所有,当该用户不再需要这个资源时,它就会被释放掉;同时,该用户还可以将资源的所有权移交给其他用户。

unique_ptr 的拷贝构造和赋值是删除的,提供了移动构造和赋值,因此要想将持有的独占资源交给其他 unique_ptr,往往需要显式地调用 std::move() 来触发移动操作。

UML 中的组合(或称复合,Composition)关系,就可以使用 unique_ptr 来建模,当整体被析构时,部分也会跟着析构。

unique_ptr 可以转换为 shared_ptr,因此 unique_ptr 很适合作为工厂函数的返回值,因为你不知道使用者需要的所有权语义究竟是独占的还是共享的;相反,一旦所有权交给了 shared_ptr,就没法再转换为独占的所有权了。

C++11 中没有类似于 make_shared() 的标准库函数,应当将 new 返回的指针传递给 unique_ptr 的构造函数;C++14 中加入了 make_unique()

unique_ptr 的大小
  • 使用默认删除器的情况下,unique_ptr 内部只维护了一个指针,和原始指针大小相同

由于 unique_ptr 直接将自定义删除器存储在对象内部

  • 使用函数指针作为删除器,大小为变为两倍的原始指针
  • 使用函数对象作为删除器
    • 无状态的函数对象,比如不捕获变量的 lambda 表达式,不影响 uniqur_ptr 的大小
    • 否则,随着函数对象的大小增加而增加

为什么不捕获变量的 lambda 表达式在 unique_ptr 里不占空间?

实现上,lambda 表达式其实是个匿名类对象,如果它不捕获任何变量,就是个空的类,C++ 规定任何对象和对象成员的大小都至少是 1,即使该对象的类型是一个空的类,这就能保证相同类型的不同对象的地址总是不同的。

class Empty {}; 
class HoldsAnInt {
private: 
    int x; 
    Empty e;
};

由于上述规定的存在,导致 sizeof(HoldsAnInt) > sizeof(int)

但该规定存在例外,那就是这个空的类作为基类的时候,是不需要占据空间的。这种优化被称为空基类优化(empty base optimization,EBO)。

class HoldsAnInt: private Empty { 
private: 
  int x;
};

这种情况下,sizeof(HoldsAnInt) == sizeof(int)

我们查看 unique_ptr 的源码,会发现它是这样存储指针和删除器的:

tuple<pointer, _Dp> _M_t;

gcc 的 tuple 的实现上应用 EBO 做空间压缩,所以不捕获变量的 lambda 表达式作为删除器时,unique_ptr 的空间不会变大。

对于程序员来说,用不捕获变量的 lambda 表达式做删除器是非常常见的情况,所以这是一个很有价值的优化。

auto_ptr 的缺陷

auto_ptr 是早期标准库中实现的一种智能指针,具有 unique_ptr 的部分特性,它用拷贝来模拟资源所有权的移交,拷贝 auto_ptr 会导致源 auto_ptr 被设为 null,这种行为是比较匪夷所思的。

std::auto_ptr<Invesetment> pInv2(pInv1);    // pInv1 被设为 null
pInv1 = pInv2;    // pInv2 被设为 null

假设将 auto_ptr 存储到容器里,并使用泛型算法对容器做操作,由于泛型算法可能将元素拷贝到局部临时对象中,会导致操作后的容器里存在大量空的 auto_ptr,因此 auto_ptr 不能和容器一起使用。

和 unique_ptr 作比较,unique_ptr 仅允许移动操作,而禁止了拷贝操作,语义更加清晰且安全。

自定义删除器

shared_ptr 和 unique_ptr 都允许自定义删除器,区别在于 unique_ptr 的自定义删除器是模板参数的一部分,而 shared_ptr 仅仅是作为构造函数的一个参数。

auto loggingDel = [](Widget *pw)        // 自定义删除器
                {
                    makeLogEntry(pw);
                    delete pw;
                };

// 删除器类型是指针类型的一部分
std::unique_ptr<Widget, decltype(loggingDel)> upw(new Widget, loggingDel);

// 删除器类型不是指针类型的一部分
std::shared_ptr<Widget> spw(new Widget, loggingDel);

不包含删除器类型模板参数给了 shared_ptr 更大的灵活性,比如 std::shared_ptr<Widget> 的容器中可以放删除器不同的各种 Widget 对象。

shared_ptr 的大小不会随着自定义删除器的大小而增加,因为这部分是放在它的控制块对象里;但 uniqur_ptr 是直接将删除器存到指针对象内了,因此它的大小是会随着自定义删除器的大小变化的。

智能指针和动态数组 shared_ptr 和动态数组

shared_ptr 不支持动态数组的管理,将动态数组传递给它后,它仍会使用 delete,而不是 delete[] 去释放这块内存,因此必须提供自己的删除器。

可以直接使用 default_delete 类型作为自定义删除器,这个类提供了针对数组类型的偏特化,会调用 delete[] 来释放内存。

std::shared_ptr<int> sp3(new int[10](), std::default_delete<int[]>());

同时,由于 shared_ptr 没有提供下标运算符,要访问数组中的元素,必须通过 get() 获取内置指针,用它来访问数组元素。

作为替代,可以使用 boost 提供的 boost::scoped_arrayboost::shared_array 来管理动态数组。

C++17 的改进

支持直接用数组作为模板参数,它会正确地调用 delete[],且增加了下标运算符:

std::shared_ptr<int[]> sp3(new int[10]());
int i = sp3[2];
使用 unique_ptr 管理动态数组

在类型名后面加 [],它会自动调用 delete[] 来释放内存,且可以使用下标运算符访问其中的元素。

unique_ptr<int[]> int_array(new int[10]{ 1, 2, 3 });
cout << int_array[1] << endl;

但比起使用 unique_ptr,更应该优先考虑 std::arraystd::vectorstd::string 等数据容器。

RAII RAII 简介

Resource Acquisition Is Initialization (RAII),即获取到资源后立刻移交给资源管理对象。资源管理对象使用它们的析构函数确保资源被释放。这里说的资源可以是内存、数据库连接、互斥锁等各种形式的资源。

假设有一个 C 风格 API 的 Mutex 类:

void lock(Mutex *pm);
void unlock(Mutex *pm);

Mutex 的资源管理类(C++11 中类似的类叫 std::lock_guard)可以定义为:

class LockGuard
{
public:
    explicit LockGuard(Mutex* pm) :mutexPtr(pm) { lock(mutexPtr); }
     ~LockGuard() { unlock(mutexPtr); }
private:
    Mutex* mutexPtr;
};

对想要写出异常安全代码的程序员来说,RAII 非常重要,因为如果在代码中显式地释放资源,就可能出现因为异常抛出而资源没能正确释放地情况,比如下面这段代码,如果 new 抛异常,mutex 就不会被解锁。

void PrettyMenu::changeBackground(std::istream& imgSrc)
{
   lock(&mutex);
   delete bgImage;
   ++imageChanges;
   bgImage = new Image(imgSrc);
   unlock(&mutex);
}

但如果改为用 RAII 的方式来管理资源,如果有异常被抛出,栈展开的过程中,资源管理对象就会被析构掉,从而释放掉被管理的资源。

void PrettyMenu::changeBackground(std::istream& imgSrc)
{
    Lock ml(&mutex);

    delete bgImage;
    ++imageChanges;
    bgImage = new Image(imgSrc);
}
用智能指针实现 RAII

C++11 后,可以通过智能指针来实现 RAII,对于共享资源,将它交给 shared_ptr,而对于独占资源,将它交给 unique_ptr,同时通过使用自定义删除器,来决定资源该怎样被释放。

shared_ptr 的实现

shared_ptr 实现上包含两个指针:一个指向被管理的对象,一个指向动态分配的控制块对象。控制块对象里包含:

  • 引用计数(use_count),用来判断是否可以释放被管理的对象;
  • 弱引用计数(weak_count),和 weak_ptr 的实现有关;
  • 其他数据,比如自定义删除器。

模拟隐式转换行为

智能指针可以模拟指针的隐式转换行为,自动将派生类指针转换为基类指针,为了做到这点,需要为智能指针增加一个泛化拷贝构造函数:

template<typename T> 
class SmartPtr { 
public: 
    template<typename U>
    SmartPtr(const SmartPtr<U>& other): heldPtr(other.get()) 
    { 
        //... 
    }
    T* get() const { return heldPtr; }
    //...
    private:
    T *heldPtr;
};

这个泛化拷贝构造函数不是 explicit 的,以支持隐式转换;同时它的初始化列表告诉我们只有能隐式转换为 T* 类型的 U* 才能通过编译。

源码分析

下面包含一些 gcc 的源码分析,不想看代码的读者可以直接跳过本章。

gcc 中控制块对象的类叫 _Sp_counted_base,包含两个引用计数,它们都是原子类型:

template<_Lock_policy _Lp = __default_lock_policy>
class _Sp_counted_base : public _Mutex_base<_Lp>
{
    // ...
    _Atomic_word  _M_use_count;     // #shared
    _Atomic_word  _M_weak_count;    // #weak + (#shared != 0)
    // ... 
};

shared_ptr 中会保存指向 _Sp_counted_base 的指针。

_Sp_counted_base<_Lp>*  _M_pi;

之前我们说过 shared_ptr 的模板参数中是不包含自定义删除器类型的,这就导致 deleter 没法保存在 shared_ptr 内部。

template< class T > class shared_ptr;   // shared_ptr 的声明

template< class Y, class Deleter >
shared_ptr( Y* ptr, Deleter d );    // 带自定义删除器的构造函数

很显然,deleter 只能存放在控制块对象中。为此,_Sp_counted_base 有一个带删除器模板参数的派生类 _Sp_counted_deleter

template<typename _Ptr, typename _Deleter, typename _Alloc, _Lock_policy _Lp>
class _Sp_counted_deleter final : public _Sp_counted_base<_Lp>

这些类之间的关系如下图所示:

当创建 shared_ptr 时,会动态分配 _Sp_counted_deleter 对象,并将自定义删除器存到它里面。

template<typename _Ptr, typename _Deleter, typename _Alloc,
typename = typename __not_alloc_shared_tag<_Deleter>::type>
__shared_count(_Ptr __p, _Deleter __d, _Alloc __a) : _M_pi(0)
{
  typedef _Sp_counted_deleter<_Ptr, _Deleter, _Alloc, _Lp> _Sp_cd_type;
  __try
    {
        typename _Sp_cd_type::__allocator_type __a2(__a);
        auto __guard = std::__allocate_guarded(__a2);
        _Sp_cd_type* __mem = __guard.get();
        ::new (__mem) _Sp_cd_type(__p, std::move(__d), std::move(__a));
        _M_pi = __mem;
        __guard = nullptr;
    }
    __catch(...)
    {
        __d(__p); // Call _Deleter on __p.
        __throw_exception_again;
    }
}

shared_ptr 析构的时候,_M_pi->_M_release() 会被调用,(原子地)减少引用计数:

void _M_release() // nothrow
{
    _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();

    if (_Mutex_base<_Lp>::_S_need_barriers) {
        __atomic_thread_fence(__ATOMIC_ACQ_REL);
    }

    _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();
    }
    }
}

如果 use_count 减少到 0,调用虚函数 _M_dispose(),其实调用到的是_Sp_counted_deleter 的实现,由此,自定义删除器被用来销毁被管理的对象。

如果 weak_count 减少到 0,调用 _M_destroy(),销毁控制块对象。

virtual void _M_dispose() noexcept
{ 
    _M_impl._M_del()(_M_impl._M_ptr); 
}

virtual void _M_destroy() noexcept
{
    __allocator_type __a(_M_impl._M_alloc());
    __allocated_ptr<__allocator_type> __guard_ptr{ __a, this };
    this->~_Sp_counted_deleter();
}

在不定义自定义删除器的情况下,如果被管理对象是是非数组类型,_M_pi 指向_Sp_counted_deleter 的默认实现 _Sp_counted_ptr,它直接调 delete 析构被管理对象。

virtual void _M_dispose() noexcept
{ 
    delete _M_ptr; 
}

virtual void _M_destroy() noexcept
{ 
    delete this; 
}

但如果被管理对象是是数组类型,自定义删除器将被设置为 __sp_array_delete,它调用 delete[] 来析构对象。

struct __sp_array_delete
{
    template<typename _Yp> void operator() (_Yp* __p) const { delete[] __p; }
};
shared_ptr 的性能分析
  • 大小是原始指针的两倍,因为它要同时持有指向被管理对象的指针和控制块对象的指针;
  • 引用计数的内存必须是动态分配的,可以用 make_shared 来对这点做优化;
  • 引用计数操作是原子的,原子操作比非原子操作要慢;
  • 控制块对象包含继承关系,为了正确的销毁对象使用了虚函数,因此对象销毁的时候要承担虚函数带来的开销。
移动和引用计数

用一个 shared_ptr 移动构造另一个 shared_ptr 不会导致引用计数的变化,新的 shared_ptr 会直接接管老的 shared_ptr 的控制块对象,因此 shared_ptr 的移动操作要比拷贝操作高效。

weak_ptr

weak_ptr 不负责对象的生命周期管理,它指向一个由 shared_ptr 管理的对象,但不改变它的引用计数(use_count)。通过 weak_ptr 可以判它所指向的对象是否已经被销毁。有两种方法可以做这种判断:

  • 尝试用 lock() 提升它为 shared_ptr,如果过期,返回的结果为空;
  • 用它构造一个新的 shared_ptr,如果过期,会抛 std::bad_weak_ptr 异常。
auto spw2 = wpw.lock();
std::shared_ptr<Widget> spw3(wpw);
weak_ptr 的实现

weak_ptr 的实现和 shared_ptr 的控制块对象相关。

由于 weak_ptr 想要知道 shared_ptr 管理的对象是否已经被析构了,那么最直接的手段就是让它访问 shared_ptr 的控制块对象,查看 use_count 是否已经是 0。

控制块对象的生命周期必须延续到所有 shared_ptr 和 weak_ptr 都已经析构掉,它才可以析构。所以需要一个控制块对象的引用计数来管理它的生命周期,即 weak_count。

weak_ptr 的使用场景

shared_ptr 可能悬空的情况下,都可以使用 weak_ptr 来做 shared_ptr 是否悬空的判断。比如 UML 中的聚合(aggregation)关系,一般由整体持有部分的 shared_ptr,部分持有整体的 weak_ptr,并使用升级操作,来判断整体是否还存活。

带缓存的工厂函数

假设说有一个开销很大的工厂函数,它针对不同的 ID 产生不同的产品,但该工厂函数的开销很大,我们希望能缓存下来它的产品:

std::shared_ptr<const Widget> loadWidget(WidgetID id);

我们希望当工厂函数客户端不再需要该缓存对象时,该对象可以被析构,因此我们用哈希表存储对象的 weak_ptr 来做缓存,获取对象时,先尝试升级缓存中的 weak_ptr,如果能成功,说明对象仍未被释放,可以节省调用工厂函数的开销:

std::shared_ptr<const Widget> fastLoadWidget(WidgetID id)
{
    static std::unordered_map<WidgetID,
                              std::weak_ptr<const Widget>> cache;
                                
    auto objPtr = cache[id].lock();    

    if (!objPtr) {                      
        objPtr = loadWidget(id);        
        cache[id] = objPtr;             
    }
    return objPtr;
}
观察者模式

观察者模式允许我们实现一种“发布-订阅”机制,当对象的状态发生变化时,通知正在“观察”该对象的其他对象。

观察者模式中有两种角色:subject 或 publisher 是状态会发生变化的对象;observer 或 subscriber 是在 subject 状态发生变化时要(通过调用 observer 的 update 接口)通知的对象。

如果使用裸指针来保存 observer,有可能发生的是 observer 已经被析构,但 subject 还不知道,又调用了 observer 的 update 方法,导致未定义行为。

解决方法是用 weak_ptr 保存 observer,在调用 update 前先升级为 shared_ptr,如果 observer 仍存活就调用 update,否则将它从 observer 列表中删除。

解决循环引用

在上图中,如果 B 也有指向 A 的引用,这时就不能选择 shared_ptr,因为如果有多个 shared_ptr 的引用关系形成环状,会导致这些指针的引用计数永远都不会归零,结果就是这些对象永远都不会被释放,即使程序中的其他部分已经不持有指向它们的智能指针。

如果我们使用裸指针,就可能出现 A 已经被析构了,B 还尝试调用它的方法,导致未定义行为。

解决方法:将引用链中的一个指针改为使用 weak_ptr 从而打破环状关系。

shared_ptr 的线程安全性 智能指针本身的线程安全

如果多个线程在不同的 shared_ptr 对象(即使这些对象是拷贝出来的,共享同一个对象的所有权)上不加同步地调用任何成员函数(包括拷贝和赋值),都是线程安全的。

如果多个线程不加同步地访问同一个 shared_ptr 对象,并且有线程使用了非 const 的成员函数(拷贝和赋值也是非 const 的),那么会发生数据竞争。虽然智能指针针对引用计数的操作是原子的,但是非 const 的成员函数往往涉及多个操作,这些操作组合在一起不是原子的。

被管理对象的线程安全

使用多个不同的 shared_ptr 对象访问同一个被管理对象,如果对该对象的操作本身不是线程安全的,那么即使通过智能指针访问,也会发生数据竞争,智能指针并不对被管理对象的线程安全性负责。

enable_shared_from_this

之前我们说过,当你持有一个 shared_ptr ,绝不应该再从它的原始指针(不管是 new 出来的还是通过 get() 得到的)中创建出一个新的 shared_ptr ,因为它们的引用计数是不共享的,会带来 double free 的问题。对于这点,即使是 this 指针也不例外。

struct S
{
  shared_ptr<S> dangerous()
  {
     return shared_ptr<S>(this);   // don't do this!
  }
};

int main()
{
   shared_ptr<S> sp1(new S);
   shared_ptr<S> sp2 = sp1->dangerous();
   return 0;
}

在这个例子中,智能指针 sp1 和 sp2 指向的是同一个底层对象,但 sp1 和 sp2 对此一无所知,它们各自管理自己的引用计数,因此这块内存会被释放两次。

要避免此问题,可以使用类模板 enable_shared_from_this,以它的派生类作为模板实参,这种继承的模式被称为 curiously recurring template pattern(CRTP)。

struct S : enable_shared_from_this<S>
{
  shared_ptr<S> not_dangerous()
  {
    return shared_from_this();
  }
};

int main()
{
   shared_ptr<S> sp1(new S);
   shared_ptr<S> sp2 = sp1->not_dangerous();
   return 0;
}
使用场景

有时候对象可能需要获得一个指向自己的 shared_ptr,以传递给 lambda 表达式或消息队列的时候,就需要调用 shared_from_this()

boost::asio::async_write(socket_, boost::asio::buffer(message_),
      boost::bind(&tcp_connection::handle_write, shared_from_this()));

上面这个例子来自 asio 的教程,asio 服务器会为每个客户端连接动态创建一个 tcp_connection 对象(包含连接的上下文信息),并在上面执行异步操作,所以必须保证 tcp_connection 对象存活到回调函数被调用的时候。

但由于异步操作的特点,你不知道回调函数 handle_write 什么时候会被调用,所以很难直接去管理 tcp_connection 的生命周期,通常的做法是用 shared_ptr 来管理它,并且让异步操作捕获一份它的 shared_ptr(不管是通过 std::bind 还是 lambda 表达式的捕获列表),这样只要异步操作还未执行,tcp_connection 对象就不会被析构。

如果在 tcp_connection 的成员函数中要执行异步操作,就必须捕获一个指向自己的 shared_ptr,这时候就需要调用 shared_from_this(),因此 tcp_connection 必须继承 enable_shared_from_this。

使用限制

必须通过 shared_ptr 来调用 shared_from_this(),下面的代码是错误的:

int main()
{
   S *p = new S;
   shared_ptr<S> sp2 = p->not_dangerous();     // don't do this
}

此外,shared_from_this() 不能在构造函数里被调用。

参考材料
  • [1] C++ Primer
  • [2] Effective Modern C++
  • [3] Effective C++
  • [4] Linux多线程服务端编程 使用muduo C++网络库

上一篇:聊聊保证线程安全的10个小技巧
下一篇:没有了
网友评论