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 06:29:12

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

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

True, that code is risky as it is right now. And that's why I had to create
the read_buffer variable.
But a more refined utility function or even base class could help avoid
some of the risks and make the code even shorter (e.g. replace with one
function call bind_executor(self.get_executor(), ..)).