On Wed, Jul 12, 2017 at 8:15 PM, Edward Diener via Boost
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