Re: [Boost-users] [Asio/Beast] Any non-obvious reasons for no bind_executor_and_allocator?

20 Dec 2018

      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
 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/wri...
...
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