Boost.asio 和异步链，unique_ptr？
Boost.asio and asynchronous chain, unique_ptr?
我对异步编程不是很熟悉，我有一个问题。
我的问题如下。给定 boost.asio 中 C++11 的 echo_server 示例：http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/example/cpp11/spawn/echo_server.cpp
我想知道是否可以将 C++14 中的 std::make_shared<session> 替换为 C++14 中的 std::unique_ptr<session>，从而避免引用计数的开销。
我不确定，因为我们有 shared_from_this() 但没有像 unique_from_this() 这样的东西，所以我怎样才能从 this 内部访问 unique_ptr<session>？
不，在 asio 编程中使用 shared_ptr 是惯用的。
想法是未完成处理程序的数量与启动异步操作的对象的共享计数相匹配。这是通过将管理对象的 shared_ptr 副本绑定到处理函数对象中来实现的。
c++11/14 的方法是将 boost::shared_ptr 替换为 std::shared_ptr（std::bind、lambda 等也可以与 asio 完美配合）。
更新，现在我完全理解了问题：
在您链接的示例中，我认为您指的是在方法 go() 中创建的名为 self 的 shared_ptr ？如果你愿意，你可以在没有 shared_ptr 的情况下编写它。您必须将 delete this 作为 go() 的最后一行。您还必须记住捕获任何异常以确保采用此代码路径。当然可以设置一个 unique_ptr 来执行此操作，但是在构建会话和成功创建采用 unique_ptr 之间存在生命周期管理问题。 shared_ptr减轻了一个原子公司成本的管理负担...
在这种情况下，答案是严格的 "yes"，但恕我直言，我会建议它更脆弱。
As I understand it, your session object will go through a pipeline of handlers, one at a time. The state of your session is never shared. Why a unique_ptr would not make sense? The point is that when the latest handler is finished, the memory will be released. Does this hold true?
是的，这就是诀窍。该库是围绕可复制的完成处理程序设计的。
如果您担心开销，请确实避免 shared_ptr。
在那种情况下，只需引用一些具有外部控制生命周期的状态。只需确保它保持活动状态（就像您对 io_service 对象本身所做的那样）。
我对异步编程不是很熟悉，我有一个问题。
我的问题如下。给定 boost.asio 中 C++11 的 echo_server 示例：http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/example/cpp11/spawn/echo_server.cpp
我想知道是否可以将 C++14 中的 std::make_shared<session> 替换为 C++14 中的 std::unique_ptr<session>，从而避免引用计数的开销。
我不确定，因为我们有 shared_from_this() 但没有像 unique_from_this() 这样的东西，所以我怎样才能从 this 内部访问 unique_ptr<session>？
不，在 asio 编程中使用 shared_ptr 是惯用的。
想法是未完成处理程序的数量与启动异步操作的对象的共享计数相匹配。这是通过将管理对象的 shared_ptr 副本绑定到处理函数对象中来实现的。
c++11/14 的方法是将 boost::shared_ptr 替换为 std::shared_ptr（std::bind、lambda 等也可以与 asio 完美配合）。
更新，现在我完全理解了问题：
在您链接的示例中，我认为您指的是在方法 go() 中创建的名为 self 的 shared_ptr ？如果你愿意，你可以在没有 shared_ptr 的情况下编写它。您必须将 delete this 作为 go() 的最后一行。您还必须记住捕获任何异常以确保采用此代码路径。当然可以设置一个 unique_ptr 来执行此操作，但是在构建会话和成功创建采用 unique_ptr 之间存在生命周期管理问题。 shared_ptr减轻了一个原子公司成本的管理负担...
在这种情况下，答案是严格的 "yes"，但恕我直言，我会建议它更脆弱。
As I understand it, your session object will go through a pipeline of handlers, one at a time. The state of your session is never shared. Why a unique_ptr would not make sense? The point is that when the latest handler is finished, the memory will be released. Does this hold true?
是的，这就是诀窍。该库是围绕可复制的完成处理程序设计的。
如果您担心开销，请确实避免 shared_ptr。
在那种情况下，只需引用一些具有外部控制生命周期的状态。只需确保它保持活动状态（就像您对 io_service 对象本身所做的那样）。