On Wed, Dec 19, 2018 at 9:37 PM Sorin Fetche wrote:

And this is what I have in mind: ... self.socket.async_read_some( read_buffer, asio::bind_executor( self.get_executor(), [self = std::move(self)](error_code ec, std::size_t bytes) mutable { if (!ec) { /* ... */ } else { self.user_completion_handler(ec, bytes); } }));

I sense danger here. The order of evaluation of function arguments is not defined. If the lambda is constructed first, then the call to `self.get_executor()` will be performed on a moved-from object. I could be wrong though... Regards

On Wed, Dec 19, 2018 at 9:37 PM Sorin Fetche wrote:

And this is what I have in mind:

https://github.com/sorf/cpp-playground/blob/master/source/asio_echo.cpp#L45

Have you considered writing a base class which takes ownership of the user's completion handler and has the necessary hooks? Then you can simply derive from it in your function-level class declaration to get all the hooks. Such a base class might look like this: template class operation_base { template friend struct boost::asio::associated_executor; Handler handler_; protected: Handler const& handler() const noexcept { return handler_; } Handler& handler() noexcept { return handler_; } public: operation_base(operation_base&&) = default; operation_base(operation_base const&) = default; operation_base& operator=(operation_base&&) = delete; operation_base& operator=(operation_base const&) = delete; explicit operation_base(Handler&& handler) : handler_(std::move(handler)) { } explicit operation_base(Handler const& handler) : handler_(handler) { } using allocator_type = boost::asio::associated_allocator_t<Handler>; allocator_type get_allocator() const noexcept { return boost::asio::get_associated_allocator(handler_); } template<class Function> friend void asio_handler_invoke(Function&& f, operation_base* op) { using boost::asio::asio_handler_invoke; asio_handler_invoke(f, std::addressof(op->handler_)); } friend bool asio_handler_is_continuation(operation_base* op) { using boost::asio::asio_handler_is_continuation; return asio_handler_is_continuation( std::addressof(op->handler_)); } }; namespace boost { namespace asio { template struct associated_executor< operation_base, Executor> { using type = typename associated_executor::type; static type get(operation_base const& op, Executor const& ex = Executor()) noexcept { return associated_executor< Handler, Executor>::get(op.handler_, ex); } }; } // asio } // boost Disclaimer: Untested. The class uses CRTP in order for the associated_executor specialization to be selected when passing the derived type. Regards

On Thu, Dec 20, 2018 at 9:25 AM Sorin Fetche wrote:

On Wed, Dec 19, 2018 at 10:24 PM Vinnie Falco wrote:

...

Have you considered writing a base class which takes ownership of the user's completion handler and has the necessary hooks?

<snip>

Yes, the base class is a very good idea. It helps reduce the boilerplate in the composed operation and the risk of moving `this` before accessing things in it.

Here's how its usage looks like to implement the composed operation: https://github.com/sorf/cpp-playground/blob/master/source/asio_echo_v2.cpp#L...

<snip>

I still don't like the risk of moving `this` (or `self`) before members in the derived class are used to initiate the next operation (e.g. the echo_buffer).

From this perspective it is similar to beast::handler_ptr. It also uses a bind_allocator utility similar to asio::bind_executor -

With some additional work on the async state helper class, the example composed asynchronous operation becomes pretty compact: https://github.com/sorf/cpp-playground/blob/master/source/asio_echo_v3.cpp#L... \code template auto async_echo_rw(StreamSocket &socket, CompletionToken &&token) -> /*...*/ { struct state_data { /*...*/}; using state_type = async_state; state_type state{std::move(completion.completion_handler), socket.get_executor(), socket, /*...*/}; state_data *data = state.get(); data->socket.async_read_some( asio::buffer(data->echo_buffer), state.wrap()([=, state = std::move(state)]( error_code ec, std::size_t bytes) mutable { if (!ec) { asio::async_write(data->socket, /*...*/); } else { state.invoke(ec, bytes); } })); return completion.result.get(); } \endcode The helper class async_state addresses now both the risk of accessing state after it has been moved and the using of the final handler to allocate the internal state. the thing that started this email thread. I haven't tested it in depth yet to confirm that the final handler allocator and executor are properly used in the internal operations, but I would welcome feedback about this async_state helper class. Would it worth trying to turn it into some general purpose utility? Any caveats about asynchronous operations it left unaddressed? https://github.com/sorf/cpp-playground/blob/master/source/asio_echo_v3.cpp#L... Best regards, Sorin