升压shared_from_this<>()

Question

有人可以用几句话概括一下应该如何使用 boost shared_from_this<>() 智能指针，特别是从使用绑定函数在 io_service 中注册处理程序的角度来看。

编辑：一些回复要求提供更多背景信息。基本上，我正在寻找“陷阱”，即人们使用这种机制观察到的反直觉行为。

Answer 1

我遇到的最大的“问题”是从构造函数中调用shared_from_this是非法的。这直接遵循以下规则：在调用shared_from_this之前，对象的shared_ptr必须存在。

Answer 2

根据我的理解，有时在您的代码中，您希望一个类向其自身提供 shared_ptr ，以便代码的其他部分可以在构造类的对象后获取该类的对象的 shared_ptr 。

问题是，如果你的类只有一个 shared_ptr<> 作为成员变量，它永远不会被自动破坏，因为总是有“最后一个引用”挂在自己身上。继承enable_shared_from_this为您的类提供了一个自动方法，该方法不仅返回一个shared_ptr，而且仅将弱共享指针作为成员变量保存，以免影响引用计数。这样，当对它的最后一个引用消失时，您的类将像往常一样被释放。

我从未使用过它，但这是我对其工作原理的理解。

Answer 3

如果对象想要访问指向其自身的 shared_ptr，则使用 shared_from_this<>。

通常，对象只知道隐式 this 指针，而不知道任何管理它的 shared_ptr 。此外，this 无法轻松转换为与其他现有 shared_ptr 实例共享所有权的 shared_ptr，因此没有对象获取其自身的有效 shared_ptr 的简单方法。

shared_from_this<>可以用来解决这个问题。例如：

struct A : boost::enable_shared_from_this<A> {
   server *io;
   // ...

   void register_self() {
      io->add_client(shared_from_this());
   }
};

Answer 4

boost::asio::io_service 析构函数文档解释得相当好

描述的破坏顺序
以上允许程序简化
他们的资源管理通过使用
共享_ptr<>。物体所在的地方
生命周期与一个人的生命周期息息相关
连接（或其他一些序列
异步操作），一个shared_ptr
到该对象将被绑定到
所有异步的处理程序
与其相关的操作。这
工作原理如下：

• 当单个连接结束时，所有关联的异步操作
  完全的。对应的处理程序
  物体被摧毁，所有
  对象的shared_ptr引用
  被摧毁。
• 要关闭整个程序，需要调用 io_service 函数 stop()
  尽快终止任何 run() 调用
  尽可能。 io_service 析构函数
  上面定义的销毁所有处理程序，
  导致所有shared_ptr引用
  所有连接对象
  被毁了。

通常，您的对象将链接异步操作，其中处理程序使用 boost::bind 和 boost::shared_from_this() 绑定到成员函数。有一些示例使用这个概念。

Answer 5

上面的一些评论缺少一些内容。这是一个对我有帮助的示例：

Boost enable_shared_from_this 示例

对我来说，我一直在与坏弱指针的错误作斗争。您必须以shared_ptr方式分配您的对象：

class SyncSocket: public boost::enable_shared_from_this<SyncSocket>

并像这样分配一个：

boost::shared_ptr<SyncSocket> socket(new SyncSocket);

然后您可以执行以下操作：

socket->connect(...);

很多示例向您展示如何使用shared_from_this()，如下所示：

boost::asio::async_read_until(socket, receiveBuffer, haveData,
        boost::bind(&SyncSocket::dataReceived, shared_from_this(), boost::asio::placeholders::error));

但我缺少的是使用shared_ptr来分配开始的对象。