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

Subject: Re: [Boost-users] [Asio/Beast] Any non-obvious reasons for no bind_executor_and_allocator?
From: Sorin Fetche (sorin.fetche_at_[hidden])
Date: 2018-12-20 05:36:54

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_at_[hidden]> 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