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? 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? -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.