Boost logo

Boost Users :

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:
> <
> >

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:

            [self = std::move(self)](error_code ec, std::size_t bytes)
mutable {
                if (!ec) {
                    /* ... */
                } else {
                    self.user_completion_handler(ec, bytes);

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,

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at