On Dec 6, 2009, at 4:51 AM, Andreas Huber wrote:
So I guess for the use cases you encountered, I doesn't make much difference whether you'd use MSM or Statechart, right?
Exactly. I want to find cases where it *does* matter, so I can justify another SFM library in Boost. I have tried the last few days to create toy-but-real-time apps with high load to see what gives.
Ok then, but you do realize that your original statement ...
MSM and Statechart do not merely overlap, the do the exact same thing: letting the developer specify and execute a state machine.
... does come across as pretty universal?
First of all, sorry about the "SFM"... Yes. If either one of you had had a radically different approach to the representation of states, for instance as enums, or had used Boost.Signal for the events and/or actions, or one of the libraries did not support nested machines at all, then, yes, I could retract such a universal (is that a bad thing? ;-)) comment.
I mean there's no headroom here like "For my use cases ..." or "To me ...". In absence of such qualifiers the reader must assume that you think that from a purely functional POV the two libraries are exchangeable for *all* possible uses. Add your remarks regarding library removal and the reader must IMO come to the conclusion that you think *all* users will be better served with MSM once compilers catch up. For sure, MSM *does* look terrific and may well satisfy a good majority of FSM implementers but there are certain use cases (e.g. multi-TU FSMs) that MSM will probably never support. OTOH, Statechart will e.g. never be able to guarantee O(1) dispatch.
So yes, there *is* overlap but it is certainly far from total, right?
Not far from, no. If you bring up one feature, multi-TU FSM, I would not call that "far". The overlap is 95%. No? Just look at the feature list of your own library, Statechart, as described in the Overview section. Which one of those features does *not* apply to MSM? /David