Re: [boost] Meta State Machine library review starts Monday

Subject: Re: [boost] Meta State Machine library review starts Monday
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2009-11-29 17:59:30

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