如何用enable_shared_from_this 来得到指向自身的shared_ptr 及对enable_shared_from_this 的理解

在看《Linux多线程服务端编程:使用muduo C++网络库》 的时候,在说到如何防止在将对象的 this 指针作为返回值返回给了调用者时可能会造成的 core dump。需使用 enable_share_from_this。

  首先要说明的一个问题是如何安全地将 this 指针返回给调用者。一般来说,我们不能直接将 this 指针返回。想象这样的情况,该函数将 this 指针返回到外部某个变量保存,然后这个对象自身已经析构了,但外部变量并不知道,那么此时如果外部变量使用这个指针,就会使得程序崩溃。

  那么使用智能指针 shared_ptr 呢?当然,使得 c++ 指针安全目前来说最有效也使用最多的办法就是使用智能指针 shared_ptr。但问题是这里要怎么去使用它。首先假设你已经理解shared_ptr 的工作原理。然后我们来看下面一份代码:

#include <iostream>
#include <memory>

class Bad {
public:
    Bad() { std::cout << "Bad()" << std::endl; }
    ~Bad() { std::cout << "~Bad()" << std::endl; }
    std::shared_ptr<Bad> getPtr() {
        return std::shared_ptr<Bad>(this);
    }
};

int main(int argc, char const *argv[])
{
    std::shared_ptr<Bad> bp1(new Bad);
    std::shared_ptr<Bad> bp2 = bp1->getPtr();
    std::cout << "bp2.use_count: " << bp2.use_count() << std::endl;
    return 0;
}

程序执行结果为:

Bad()
bp2.use_count: 1
~Bad()
~Bad()
a(822,0x7fff737b5300) malloc: *** error for object 0x7fe74bc04b50: pointer being freed was not allocated

我们可以看到,对象只构造了一次,但却析构了两次。并且在增加一个指向的时候 shared_ptr的计数并没有增加。也就是说,这个时候 bp1 和 bp2 都认为只有自己才是这个智能指针的拥有者。其实也就是说,这里建了两个智能指针同时处理 this 指针。每个智能指针在计数为0的时候都会调用一次Bad对象的析构函数。所以会出问题。

  其实现在问题就变成了,如何在对象中获得一个指向当前对象的 shared_ptr 对象。如果我们能够做到这个,那么直接将这个shared_ptr 对象返回,就不会造成新建 shared_ptr 的问题了。

  下面来看看 enable_shared_from_this;

  enable_shared_from_this 是一个以其派生类为模板类型实参的基类模板,继承它,派生类的this指针就能变成一个 shared_ptr。先来看下面一份代码:

#include <iostream>
#include <memory>

class Good: public std::enable_shared_from_this<Good>{
public:
    Good() { std::cout << "Good()" << std::endl; }
    ~Good() { std::cout << "~Good()" << std::endl; }

    std::shared_ptr<Good> getPtr() {
        return shared_from_this();
    }
};

int main(int argc, char const *argv[])
{
    std::shared_ptr<Good> bp1(new Good);
    std::shared_ptr<Good> bp2 = bp1->getPtr();
    std::cout << "bp2.use_count: " << bp2.use_count() << std::endl;
    return 0;
}

执行结果:

Good()
bp2.use_count: 2
~Good()

解决问题了。

那么下面就来看看 enable_shared_from_this 到底是怎么工作的:这是它的实现源码:

template<class T> class enable_shared_from_this
{
protected:

    enable_shared_from_this() BOOST_NOEXCEPT
    {
    }

    enable_shared_from_this(enable_shared_from_this const &) BOOST_NOEXCEPT
    {
    }

    enable_shared_from_this & operator=(enable_shared_from_this const &) BOOST_NOEXCEPT
    {
        return *this;
    }

    ~enable_shared_from_this() BOOST_NOEXCEPT // ~weak_ptr<T> newer throws, so this call also must not throw
    {
    }

public:

    shared_ptr<T> shared_from_this()
    {
        shared_ptr<T> p( weak_this_ );
        BOOST_ASSERT( p.get() == this );
        return p;
    }

    shared_ptr<T const> shared_from_this() const
    {
        shared_ptr<T const> p( weak_this_ );
        BOOST_ASSERT( p.get() == this );
        return p;
    }

public: // actually private, but avoids compiler template friendship issues

    // Note: invoked automatically by shared_ptr; do not call
    template<class X, class Y> void _internal_accept_owner( shared_ptr<X> const * ppx, Y * py ) const
    {
        if( weak_this_.expired() )
        {
            weak_this_ = shared_ptr<T>( *ppx, py );
        }
    }

private:

    mutable weak_ptr<T> weak_this_;
};

  我们重点看  shared_from_this 的实现。因为我们就是用它来返回一个指向 this 的智能指针对象的。我们可以看到,这个函数使用一个 weak_ptr 对象来构造一个 shared_ptr 对象,然后将其返回。注意这个 weak_ptr 是实例对象的一个成员,所以对于一个对象来说它一直是同一个,每次在调用 shared_from_this 的时候,就会根据 weak_ptr 来构造一个临时shared_ptr对象。

  也许看到这里会产生疑问,这里的 shared_ptr 也是一个临时对象,和前面有什么区别?还有,为什么enable_shared_from_this 不直接保存一个 shared_ptr 成员?

  首先对于第一个问题,这里的每一个shared_ptr都是根据 weak_ptr 来构造的,而每次构造shared_ptr的时候使用的参数是一样的。所以这里根据相同的weak_ptr来构造多个临时 shared_ptr 等价于用一个shared_ptr进行拷贝。

  我们首先要理解,类对象肯定是外部函数通过某种机制分配的,并且如果要使用 shared_ptr 来进行管理的话,那么必须在分配完成后立即交给 shared_ptr。然后在其他地方需要用到这个对象的话也应该使用这个 shared_ptr 作为参数进行拷贝构造或赋值。而我们使用一个 weak_ptr 来进行构造 shared_ptr,作用是一样的(如果理解weak_ptr的工作原理,这个就不难理解了, weak_ptr本身就是为了协同 shared_ptr 的工作而生的)。

  那么enable_shared_from_this为什么不直接保存一个 shared_ptr 成员呢?假设我再类里面储存了一个指向自身的 shared_ptr,那么这个shared_ptr的计数最少都会是1,也就是说,这个对象永远不能析构,所以这样做是错误的。而 weak_ptr 不会引起 shared_ptr 计数的增加。

  enable_shared_from_this 的成员变量在enable_shared_from_this构造的时候是没有指向任何对象的,在第一次调用 shared_ptr 的时候,由 shared_ptr 调用 boost::detail::sp_enable_shared_from_this 然后调用enable_shared_from_this 的 _internal_accept_owner来对其进行初始化。看下面的过程就明白了。

  shared_ptr的构造:

template<class Y>
    explicit shared_ptr( Y * p ): px( p ), pn( p )
    {
        boost::detail::sp_enable_shared_from_this( this, p, p );
    }

  这里使用了 boost::detail::sp_enable_shared_from_this

template< class X, class Y, class T >
 inline void sp_enable_shared_from_this( boost::shared_ptr<X> const * ppx,
 Y const * py, boost::enable_shared_from_this< T > const * pe )
{
    if( pe != 0 )
    {
        pe->_internal_accept_owner( ppx, const_cast< Y* >( py ) );
    }
}

  而在这里面又调用 enable_shared_from_this 的 _internal_accept_owner

template<class X, class Y> void _internal_accept_owner( shared_ptr<X> const * ppx, Y * py ) const
    {
        if( weak_this_.expired() ) // 成员函数expired()的功能等价于use_count()==0
        {
            weak_this_ = shared_ptr<T>( *ppx, py );
        }
    }

  从这个构造过程可以看出,当 weak_ptr 第一次指向一个对象后,它就担起了观察者的角色,一直观察着同一个对象。

  从上面的介绍也可以看出,我们不能对一个普通对象去获取shared_ptr,比如:

Good g;
std::shared_ptr<Good> gp = g.shared_from_this();

  这样会产生错误,因为 g 并不在堆而在栈区,然后shared_ptr试图去删除一个栈区上构造的对象,就会产生未定义行为。

时间: 11-13

如何用enable_shared_from_this 来得到指向自身的shared_ptr 及对enable_shared_from_this 的理解的相关文章

关于boost中enable_shared_from_this类的原理分析

首先要说明的一个问题是:如何安全地将this指针返回给调用者.一般来说,我们不能直接将this指针返回.想象这样的情况,该函数将this指针返回到外部某个变量保存,然后这个对象自身已经析构了,但外部变量并不知道,此时如果外部变量使用这个指针,就会使得程序崩溃. 使用智能指针shared_ptr看起来是个不错的解决方法.但问题是如何去使用它呢?我们来看如下代码: #include <iostream> #include <boost/shared_ptr.hpp> class Tes

为什么要使用boost::enable_shared_from_this&lt;T&gt;

#include <boost/enable_shared_from_this.hpp> class Test : public boost::enable_shared_from_this<Test> { // ......}; boost::shared_ptr<Test> tt(new Test); 上面定义的Test类派生自boost::enable_shared_from_this<T>,获取Test类的shared_ptr的语句如上,和使用不派生

enable_shared_from_this用法分析

一.背景 在为什么需要异步编程文章末尾提到,"为了使socket和缓冲区(read或write)在整个异步操作的生命周期一直保持活动,我们需要采取特殊的保护措施.你的连接类需要继承自enabled_shared_from_this,然后在内部保存它需要的缓冲区,而且每次异步调用都要传递一个智能指针给this操作".本文就详细介绍为什么使用enabled_shared_from_this就能保证对象的生命周期,以及enabled_shared_from_this内部的具体实现分析. 二.

改变javascript函数内部this指针指向的三种方法

在查了大量的资料后,我总结了下面的三条规则,这三条规则,已经可以解决目前我所遇到的所有问题.规则0:函数本身是一个特殊类型,大多数时候,可以认为是一个变量. function a() { alert(this); } 或者 var a = function() { alert(this); } 都可以认为是创建了一个变量,这个变量的值就是一个函数. 规则1:如果一个函数,是某个对象的key 值,那么,this就指向这个对象. 这个规则很好理解: var a = function(obj) { a

JavaScript面向对象(一)——JS OOP基础与JS 中This指向详解

  前  言 JRedu 学过程序语言的都知道,我们的程序语言进化是从"面向机器".到"面向过程".再到"面向对象"一步步的发展而来.类似于汇编语言这样的面向机器的语言,随着时代的发展已经逐渐淘汰:而面向过程的语言也只有C语言老大哥依然坚挺:现在主流的语言(例如Java.C++.PHP等)都是面向对象的语言. 而我们的JavaScript语言,恰恰介于面向过程与面向对象之间,我们称它为"基于对象"的语言.但是,JS中的OOP依

javascript的this到底指向谁

新手对this最困惑. 因为javascript的面向对象比较诡异. 我们说, 通常的面向对象, 分为对象和消息. 由于一些课本的讲解问题, 大家通常认为消息就是方法, 就是函数 这个呢, 有的时候也不能说错啦.消息是抽象概念, 方法是具体实现. 而且对于像C#这类的语言来说, 基本上就是用方法来发消息. 可是对于javascript来说问题就大了. 因为对于javascript来说, 方法, 也是对象! 这下麻烦了. 那javascript还有消息么? 这个仁者见仁了. 你认为那个能发消息哪个

(转)从内存管 理、内存泄漏、内存回收探讨C++内存管理

http://www.cr173.com/html/18898_all.html 内存管理是C++最令人切齿痛恨的问题,也是C++最有争议的问题,C++高手从中获得了更好的性能,更大的自由,C++菜鸟的收获则是一遍一遍的检查代码和对 C++的痛恨,但内存管理在C++中无处不在,内存泄漏几乎在每个C++程序中都会发生,因此要想成为C++高手,内存管理一关是必须要过的,除非放弃 C++,转到Java或者.NET,他们的内存管理基本是自动的,当然你也放弃了自由和对内存的支配权,还放弃了C++超绝的性能

C++内存管理(超长,例子很详细,排版很好)

[导语] 内存管理是C++最令人切齿痛恨的问题,也是C++最有争议的问题,C++高手从中获得了更好的性能,更大的自由,C++菜鸟的收获则是一遍一遍的检查代码和对C++的痛恨,但内存管理在C++中无处不在,内存泄漏几乎在每个C++程序中都会发生,因此要想成为C++高手,内存管理一关是必须要过的,除非放弃C++,转到Java或者.NET,他们的内存管理基本是自动的,当然你也放弃了自由和对内存的支配权,还放弃了C++超绝的性能.本期专题将从内存管理.内存泄漏.内存回收这三个方面来探讨C++内存管理问题

C++中str1::function和bind

在C++的TR1中(TechnologyReport)中包括一个function模板类和bind模板函数,使用它们能够实现类似函数指针的功能,但却却比函数指针更加灵活,特别是函数指向类的非静态成员函数时.能够參考Scott Meyers. <<Effective C++ (3rdEdition)>>. Item 35.以下详细说明其用法. 一.指向全局函数或静态成员函数时 由于在本质上讲全局函数和静态成员函数没有差别,用法上除了静态成员函数在引用时要在前面加域作用符classNam