>>it took a little long but I managed to make plan A work. If you provide an internal transition table (internal_transition_table) in your fsm definition,

>> you can avoid having to define a second region with a single state. Instead you get a transition looking like this:

>>struct internal_transition_table : boost::mpl::vector<

>>Internal < event , action , guard >

>> {};

>>In this case, action and guard are functors but it works with other rows too.

>>You will need the latest trunk version.

> 

>Thanks, excellent work, I’ll give this a try. What are the trade-offs/advantages between this approach and plan b? Are there any performance

>differences, or mostly just style methodology?

 

Mostly style, though the performance is likely to be a little better. The reason is that if you have 2 regions, all events are tried in both regions, so twice the dispatch speed of one region. If you use an internal table, only those events not processed by the one region will be tried by the internal table (MSM does check at compile-time if it is worth trying an event for the internal table. If the event is not found there, it is not tried and processing stops here). Granted, it is not a huge speed gain, but any gain is happily taken ;-)

 

For the style, it allows you to provide 2 kinds of internal transitions for submachines, either as rows in the main machine, or as internal table in the submachine, so you get more flexibility.

 

Regards,

Christophe