I can't speak for the author, but I have used statechart extensively over the years. Process_event and post_event operate fundamentally differently, and I don't think it is a good idea to mask the differences by forcing them into the same API.

Think if process_event as synchronous event handling. (Do not confuse with asynchronous state machines.) The function call doesn't return until after event processing completes. If the state machine is not already in a stable state, there is no right answer to what this should do.

On the other hand, post_event queues up the event for processing once any existing event processing completes. Hence, if called from the state machine while in an unstable state, the state machine will wait to be stable before invoking the event. But the actual function call returns immediately.

The caller has to be aware of the differences. Upon return from calling post_event, event processing has not yet occurred. Upon return from process_event, it has. Theoretically you could get away with always calling post_event, but not the other way around. You have to be aware of which one you are calling.

Dan Kelly

djkelly@computer.org

(484) 769-2961

On Mar 29, 2017, at 11:06, Robert Dailey via Boost-users <boost-users@lists.boost.org> wrote:

I'm seeing a usability issue between post_event and process_event.
Basically, depending on where in the state itself I'm executing an
event, I need to know which to invoke. My understanding is that if I'm
calling within the context of the constructor of the state, I need to
use post_event. Anywhere else (outside of construction, but still
within a member function of the state subclass itself), you invoke
"context<MyMachine>().process_event()".

Why can't post_event() automatically query the state machine to see if
it is "busy" constructing a state, and if it isn't, forward the event
to process_event() for me instead? Is there really a reason to have to
make a logical decision between the two in code?

I'm using boost::statechart in my code at $DAYJOB and this is a
reasonable complaint I get in my code reviews, especially from those
not very familiar with boost itself. They have an expectation for the
implementation of the state machine to be intuitive and easy to
understand.
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users