Hi Felipe,

Why the transition table uses non-type template parameter for actions and guards instead of using a agreed function name for handling events in states?

I'm not sure I understand the question. Please excuse (and correct) me if I miss the point. You mean, why not remove action and guards from the transition table and delegate all handling to a state (source or target)? Well, you can do this if you want, as there are already such methods defined, on_entry and on_exit. So theoretically you could use a _row, which has only source state / event / target state and delegate all work to on_entry and on_exit. It would work in some cases. However, you could also have the following: _row< State1, event1, State3>, _row< State2, event2, State3> and maybe _row< State1, event3, State4> Now you have a problem in State1 and 3. State3 can be the target of 2 transitions from 2 states and State1 can be the source of 2 transitions to 2 states. Where to add the common handling? It'll fatally end with some if/else on the event type. If you carefully choose your on_entry/exit, action and guard you will avoid this and get cleaner code with on_entry and on_exit (called each time a state is entered/left independently of the event) doing the work common to all transitions and the action/guard the work specific to one event. To be honest, as on_entry and on_exit are templatized on the event you could use SFINAE to handle event-specific tasks and get rid of actions and guards anyway but SFINAE isn't everybody's tool. If you feel good with them, then sure, why not?

That should get the transition table a lot smaller and maybe even faster for not using a pointer (though speed-wise, that's a wild guess).

Luckily Msm allows you both ways :) You have a valid point with your wild guess. I'm unsure myself why but if you use the functor-based frontend, which is doing strictly the same, you will see some speed gain (about 20%) compared to the pointer version. I hope I could answer the question satisfactorily. Regards, Christophe