Boost.asio и асинхронная цепочка, unique_ptr?

Нет, использование shared_ptr в asio программировании идиоматично.

Идея состоит в том, что количество незавершенных обработчиков соответствует общему счету объекта, инициирующего асинхронные операции. Это достигается путем привязки копии shared_ptr, управляющей объектом, к объектам функции-обработчика.

Способ С++ 11/14 состоял бы в том, чтобы заменить boost::shared_ptr на std::shared_ptr (std::bind, лямбда-выражения и т. д. также отлично работают с asio).

Обновление, теперь, когда я полностью понимаю вопрос:

В приведенном вами примере, я так понимаю, вы имеете в виду shared_ptr с именем self, который создается в методе go()? Вы можете написать его без shared_ptr, если хотите. Вам нужно будет удалить это как последнюю строку go(). Вы также должны помнить, чтобы поймать любые исключения, чтобы убедиться, что этот путь кода был выбран. Уникальный_ptr, конечно, может быть настроен для этого, но тогда у вас возникнет проблема управления временем жизни между созданием сеанса и успешным созданием уникального_ptr. shared_ptr облегчает бремя управления за счет стоимости одного атомарного вкл...

В этом случае ответ строго «да», но имхо я посоветую, так как он более хрупкий.

Насколько я понимаю, ваш объект сеанса будет проходить через конвейер обработчиков, по одному. Состояние вашего сеанса никогда не передается. Почему unique_ptr не имеет смысла? Дело в том, что когда последний обработчик завершится, память будет освобождена. Верно ли это?

Да, это трюк. Библиотека была разработана на основе копируемых обработчиков завершения.

Если вы беспокоитесь о накладных расходах, действительно избегайте shared_ptr.

В этом случае просто укажите ссылку на некоторое состояние с внешним управлением временем жизни. Просто убедитесь, что он остается живым (так же, как вы делаете это с самим объектом io_service).