Hi,
On Wed, May 23, 2012 at 4:10 PM, asif saeed
What are the differences between these three libraries? I feel I can use any of these libs. Is there any page where the comparison/pros&cons are listed and so on?
Here is my understanding: Spirit allow you to generate a custom-language parser at compile-time, given a set of expressions. I don't know if it have any relationship with the finite-state-machine construct, but I think it is not it's purpose. It's purpose is to allow you to build domain-specific languages. StateChart and MSM both provide Finite-state-machine constructs. In StateChart, you write each state as child class related to it's parent state class. You set each possible event->action in the state itself. Each state have a transition table. In MSM, you setup a transition table for a state machine, you define the state separately. StateChart rely on runtime dynamic inheritance to manage states, while MSM ...well do it without inheritance. That's why it's called MSM: it's a meta state machin, so it will generate the state machine for you given a type for each state. On performance, MSM is far more efficient (in my use) but is more expensive on compile time. Both are in fact, but MSM can kill you compiler if you setup a really big state machine. Also, MSM is far easier to work with simply because it's easier to organise and read the code (if you are used to templates). Having one place to see all the relationships between the different states is really helping a lot. MSM provide diffrent ways to express your state relationships, but some (the more expressive way to me) can kill your compiler even faster. (see the doc for details) On runtime, the difference between the two is really important: Statechart will keep the instance of only one state at a time, or a state, it's substate, it's substate etc. to the state the machine is currently set to. When changing state, Statechart will first destroy (aka call 'delete') the current state (and parents if the new state is not in the same branches) and then create (aka call 'new') the new state. The constructor and destructor are assumed to contain the entry and exit code of the state. MSM on the other side, build all state objects inside the state machine on it's creation. Constructors and destructors of states are just constructors and destructors. MSM states can implement functions for entry and exit of the state, that are called when the machine enter the state and get out. There is no allocation/deallocation done while processing events (other than the event queue I suppose). That is very important for example in games or embedded contexts. Using Statechart, events have to inherit a statecharte-provided type (that use CRTP). Same thing with the states, that als have to know the parent types at compile time. Using MSM, you can provide whatever types you want for both. StateChart has still some advanges that I don't remember of but I suppose the size of the state machine instance itself can be far less than the same for MSM if it have a lot of states and data inside, because only the current states are instantiated. That said, it is still not always an option to have a state machine allocation/deallocating objects at runtime. I don'nt know if you can provide an allocator though. So, it depends on your need, but for a state machine I would use MSM by default, Statechart for specific case or legacy code (MSM is pretty new, Statechart is pretty old). Hope it helps. Joel Lamotte