Hi Simon,

I agree that the feature can be costly. I don't have a lot of experience with fsms with very tight time constraints though - SC seems to meet our time requirements (ie the state machine itself is much faster than the other operations we perform).

Sure but Msm is a general-purpose library and can therefore not allow itself not to be performant. Quite a few Msm users are from the embedded world and performance does matter there (anyway, this is C++ so it always does, right? ;-) ). Msm also proves that thanks to metaprogramming, a library can bring ease of use and speed.

...

+ your state data is always available. In my experience, state data is not only needed in the entry or when the next event is processed, but during a transition or even at some time after a transition. This means, that you have, during a transition, access to data from the source or the target state.

This is simple to emulate in SC. The state data can be owned by the outer state, or by the state_machine itself.

Sure, but then the statechart documentation itself makes a pretty good point why this is less than ideal(http://www.boost.org/doc/libs/1_40_0/libs/statechart/doc/faq.html#StateLocal...). In short, this workaround means that some data saved this way in the top-level fsm will only have a meaning in some of the states of this fsm. Doesn't this pretty much defeat the concept of state local storage itself?

...

+ combined with the visitor, you can at any time access data from the currently active state and build a generic way to do something with state data.

Granted. Personally though, I prefer to keep my fsm opaque, and force the use of events and actions to update and monitor the fsm respectively. Any other method (in our application) is a violation of the desired encapsulation.

I should have explained a bit better. What you write is exactly what the visitor concept is for. It allows you to delegate to the active state(s) an action to execute at any time, without even needing an event. Thus you keep your fsm opaque and more robust. And all this happens without rtti or virtual calls.

IMO the lack of state local storage is actually a relatively minor issue. The big ticket issue for me is its ability (or rather, the compiler's ability) to create large state machines. With SC, I might create a 50 transition state machine. Over time, normal maintenance might add another 10 or 20 transitions. This isn't a big deal. However, I'd be less likely to start developing such a state machine with msm for fear that any additional transitions might push the compiler 'over the edge'.

Granted, the limit is, for the moment, the compiler. I managed yesterday 150 transitions with g++4.3. If Msm becomes part of Boost and we report to Microsoft that g++ is beating them that much, they might find some motivation to fix their bug. If you read the beginning of this thread again (the review), you'll see that the reviewer managed 15 states and 80 transitions with VC9, which already starts being a reasonable-sized state machine. Msm is clearly not only for very small machines.

So for medium to large state machines, I would choose SC. For very small state machines, I might be tempted to choose a C style hand written state machine to avoid the learning overhead for such a trivial application (though Euml is cool enough that I might overcome that).

As you already seem to use SC quite much, learning Msm should not be such a large overhead. If you try, please let me know how it went. And if eUML is tempting you to use Msm, then it did its job :) Christophe