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?
No, as Simon has already pointed out, for some users scalability is more important than raw dispatch speed. For other users it's exactly the other way round, which is why an FSM with guaranteed O(1) dispatch would surely be a welcome addition to Boost. [snip]
+ 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?
It doesn't, but this seems to be beside the point anyway. You wrote (in an unquoted part) that Msms behavior with respect to storage in states is hard to emulate with SC. Simon only showed that it isn't (unless Simon and I are missing something).
Granted, the limit is, for the moment, the compiler. I managed yesterday 150 transitions with g++4.3.
That's good to hear. BTW, is there only a limit on the number of transitions, or is the number of states limited in some way to? Does the number or orthogonal regions have an influence? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.