
Apologies if this is a silly question as I'm not familiar with earlier versions of MSM, but how does this library different from Boost.Statechart?
This is not a silly question but one which is begging for controversy ;-) I hope this is not starting a flame war, so from my understanding, there are advantages of using Msm on several points: - speed: Msm is much faster than statechart (see the performance page. Usually more than 20 times faster). - Design: * Msm makes heavier use of metaprogramming = longer compilation, higher speed * No RTTI and no virtual functions * Msm tries to follow the principles of declarativeness described in the book "C++ Template Metaprogramming". This leads to an interface, which is, in my opinion, easier to use. * Again in my opinion, entry/exit/guards are better with Msm. With Statechart, you have to write guard handling yourself and you don't get the event as parameter in the entry/exit. * Actions / guards are more reusable as you can provide a functor object * States are also more reusable as they don't know their containing state machine or other states (due to in-state transition-table definition in Statechart) - UML support. Msm supports forks, UML-conform event dispatching in orthogonal regions (which is that every region gets a chance to handle a given event), entry/exit pseudostates and anonymous transitions (transitions without an event). - Usage: Msm also supports different frontends. For example, eUML tries to hide metaprogramming as much as possible and tries to look like an UML diagram. This also help writing state machines easier with Msm. - Model-Driven approach. You will find in the doc directory my BoostCon paper (the only PDF) where I describe my analysis of MDD with both frameworks. But this is ultimately a matter of taste (as I will of course prefer Msm and Andreas will likely prefer Statechart), and you should take whatever fits your needs better and you are more comfortable with, so I'd advise you to look at both and see what you prefer (and even better, what I could do to improve Msm).

Hi Christophe
This is not a silly question but one which is begging for controversy ;-) I hope this is not starting a flame war
:-) You won't get any flames from me. Yes, I don't agree with some of the points in MsmSession_Handout.pdf (e.g. 2.4, a user in his right mind would put Stopped, Open, Paused and Playing into an outer CDLoaded state and then only say if (state_downcast<const CDLoaded *> != 0)). However, although I haven't yet reviewed anything in-depth so far, I'm definitely impressed by the progress the library has made. I hope I'll find the time to contribute an in-depth review.
But this is ultimately a matter of taste (as I will of course prefer Msm and Andreas will likely prefer Statechart)
That really depends on the use-case. If I ever run into a scenario where raw dispatch performance is paramount, MSM 2.0 looks like it could be a strong candidate. Out of curiosity, have you made any tests how many states compilers can manage without running out of memory? IIRC, a Boost.Statechart FSM with 128 states and several hundred transitions was the most I was able to fit into one TU. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (2)
-
Andreas Huber
-
Christophe Henry