有人能用几句简洁的话总结一下应该如何使用 boost shared_from_this<>() 智能指针，特别是从使用绑定函数在 io_service 中注册处理程序的角度来看。
编辑：一些回复要求提供更多背景信息。基本上，我正在寻找“陷阱”，即人们使用这种机制观察到的违反直觉的行为。
【问题讨论】：
标签： c++ boost boost-asio boost-bind
我遇到的最大“问题”是从构造函数调用 shared_from_this 是非法的。这直接遵循以下规则：对象的 shared_ptr 必须存在才能调用 shared_from_this。
【讨论】：
shared_ptr<Type> create 方法。
据我了解，有时在您的代码中，您希望一个类为其自身提供 shared_ptr，以便您的代码的其他部分可以在构建类的对象后获取 shared_ptr。
问题是，如果你的类只有一个 shared_ptr<> 作为成员变量，它永远不会被自动销毁，因为它自己总是有“最后一个引用”。从enable_shared_from_this 继承为您的类提供了一个自动方法，该方法不仅返回shared_ptr，而且仅将弱共享指针作为成员变量保存，以免影响引用计数。这样，当最后一个引用消失时，您的类将像往常一样被释放。
我从未使用过它，但这是我对其工作原理的理解。
【讨论】：
如果对象想要访问指向自身的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());
}
};
【讨论】：
boost::asio::io_servicedestructor 文档很好地解释了它
描述的销毁顺序 以上允许程序简化 他们的资源管理通过使用 shared_ptr。一个物体在哪里 生命周期与 a 的生命周期相关联 连接（或其他一些序列 异步操作），一个 shared_ptr 到对象将被绑定到 所有异步的处理程序 与之相关的操作。这 工作如下：
- 当单个连接结束时，所有关联的异步操作 完全的。对应的处理程序 对象被销毁，所有 shared_ptr 对对象的引用 被销毁。
- 要关闭整个程序，调用 io_service 函数 stop() 尽快终止任何 run() 调用 尽可能。 io_service 析构函数 上面定义的销毁所有处理程序， 导致所有 shared_ptr 引用 所有连接对象 销毁。
通常，您的对象将链接异步操作，其中处理程序使用boost::bind 和boost::shared_from_this() 绑定到成员函数。有一些examples 使用了这个概念。
【讨论】：
上面的一些 cmets 缺少东西。这是一个帮助我的例子：
Boost enable_shared_from_this example
对我来说，我一直在为糟糕的弱指针错误而苦苦挣扎。你必须以 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 来分配对象。
【讨论】：