Boost logo

Boost :

Subject: Re: [boost] [beast] Formal review
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-07-13 03:23:51


On Wed, Jul 12, 2017 at 8:15 PM, Edward Diener via Boost
<boost_at_[hidden]> wrote:
> I was just surprised when you say that the thought never crossed your mind,
> considering that you described your code as a state machine and Boost has
> to state machine libraries

I've used Boost.Statechart in the past and the amount of additional
infrastructure in terms of types, lines, and the required splitting of
code into separate functions is just not worth it. The current
implementation is straightforward if a bit unorthodox, but that is a
consequence of the inversion of flow of control inherent when
implementing composed asynchronous operations using callbacks.

For this particular purpose, I think introducing another library's
types and methodology is a net negative. Asynchronous programming is
tricky, and its even more tricky for a library to protect users from
all possible mistakes when using callbacks (tricky as in, hardly
possible at all). Even seasoned Asio programmers sometimes make
mistakes and need to get a breakpoint in the implementation (of Asio,
or Beast). When that happens I don't want them to see
Boost;.Statechart in the innards of a composed operation callback.

Beast does use other parts of Boost, just not for state machines. It
uses Boost.Intrusive for example (GREAT library!!)

Thanks


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk