On Wed, Dec 19, 2018 at 4:57 PM Vinnie Falco wrote:
On Wed, Dec 19, 2018 at 4:31 PM Sorin Fetche via Boost-users
<boost-users@lists.boost.org> wrote:
> I did come across the paper "Networking TS Associations for Call Wrappers"[1]
> but I didn't see any mention there about bind_executor or something similar for
> allocators or why this kind of approach wouldn't work.

Eh... you have `socket_` which means you have a class, so there is
really no reason not to use the intrusive mechanism for associating
your class with the executor and allocator associated with `handler_`.
This is covered in the Beast composed operation tutorial:

<https://www.boost.org/doc/libs/1_69_0/libs/beast/doc/html/beast/using_io/writing_composed_operations.html>

Thank you for the link and yes I'm familiar with it.
Starting from it and the recent "composed" examples from Boost.Asio, I got to my question about bind_executor and lambdas.

And this is what I have in mind:

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

\code
    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);
                }
            }));
\endcode

Basically, no need to define an operator() and implement an explicit state machine in it and no need for class methods and using a flavor of bind for short completion handlers that fit in a small lambda.
As it is now it just misses the forwarding of final handler allocator to the internal operations.

Best regards,
Sorin