Check if one region of the concrete state machine is in a terminate or interrupt state. If yes, event processing is disabled while the condition lasts (forever for a terminate pseudo-state, while active for an interrupt pseudo-state).

If the message queue feature is enabled and if the state machine is already processing an event, push the currently processed event into the queue and end processing. Otherwise, remember that the state machine is now processing an event and continue.

If the state machine detected that no deferred event is used, skip this step. Otherwise, mark the first deferred event from the deferred queue as active.

Now start the core of event dispatching. If exception handling is activated, this will happen inside a try/catch block and the front-end exception_caught is called if an exception occurs.

The event is now dispatched in turn to every region, in the order defined by the initial state front-end definition. This will, for every region, call the corresponding front-end transition definition (the "row" or "Row" of the transition table).

Without transition conflict, if for a given region a transition is possible, the guard condition is checked. If it returns true, the transition processing continues and the current state’s exit action is called, followed by the transition action behavior and the new active state’s entry behavior.

With transition conflicts (several possible transitions, disambiguated by mutually exclusive guard conditions), the guard conditions are tried in reverse order of their transition definition in the transition table. The first one returning true selects its transition. Note that this is not defined by the UML standard, which simply specifies that if the guard conditions are not mutually exclusive, the state machine is ill-formed and the behaviour undefined. Relying on this implementation-specific behaviour will make it harder for the developer to support another state machine framework.

If at least one region processes the event, this event is seen as having been accepted. If not, the library calls no_transition on the state machine for every contained region.

If the currently active state is a submachine, the behaviour is slightly different. The UML standard specifies that internal transitions have to be tried first, so the event is first dispatched to the submachine. Only if the submachine does not accept the event are other (non internal) transitions tried.

This back-end supports simple states' and submachines' internal transitions. These are provided in the state’s internal_transition_table type. Transitions defined in this table are added at the end of the main state machine’s transition table, but with a lesser priority than the submachine’s transitions (defined in transition_table). This means, for simple states, that these transitions have higher priority than non-internal transitions, conform to the UML standard which gives higher priority to deeper-level transitions. For submachines, this is a non-standard addition which can help make event processing faster by giving a chance to bypass subregion processing. With standard UML, one would need to add a subregion only to process these internal transitions, which would be slower.

After the dispatching itself, the deferred event marked in step 3 (if any) now gets a chance of processing.

Then, events queued in the message queue also get a dispatching chance.

Finally, completion / anonymous transitions, if to be found in the transition table, also get their dispatching chance.

A Source typedef indicating, well, the type of the source state.

A Target typedef indicating, well, the type of the target state.

An Evt typedef indicating the type of the event triggering the transition.

A row_type_tag typedef indicating the type of the transition.

Rows having a type requiring transition actions must provide a static function action_call with the following signature: template <class Fsm,class SourceState,class TargetState,class AllStates>

Rows having a type requiring a guard must provide a static function guard_call with the following signature:``

The possible transition (row) types are:

initial_state: This typedef can be a single state or a mpl container and provides the initial states defining one or several orthogonal regions.

transition_table: This typedef is a MPL sequence of transition rows.

configuration: this typedef is a MPL sequence of known types triggering special behavior in the back-end, for example if a concrete fsm requires a message queue or exception catching.

flag_list: the flags being active when this state or state machine becomes the current state of the fsm.

deferred_events: events being automatically deferred when the state is the current state of the fsm.

internal_transition_table: the internal transitions of this state.

on_entry and on_exit methods.

generate_state_set<transition table>: returns a mpl::set of all the states defined in the table.

generate_event_set<transition table>: returns a mpl::set of all the events defined in the table.

using mpl::size<>::value you can get the number of elements in the set.

display_type defines an operator() sending typeid(Type).name() to cout.

fill_state_names fills an array of char const* with names of all states (found by typeid).

using mpl::for_each on the result of generate_state_set and generate_event_set passing display_type as argument will display all the states of the state machine.

let’s suppose you need to recursively find the states and events defined in the composite states and thus also having a transition table. Calling recursive_get_transition_table<Composite> will return you the transition table of the composite state, recursively adding the transition tables of all sub-state machines and sub-sub…​-sub-state machines. Then call generate_state_set or generate_event_set on the result to get the full list of states and events.