Re: [Boost-users] Spirit, StateChart, MSM

Subject: Re: [Boost-users] Spirit, StateChart, MSM
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2012-05-23 05:49:18

Hi,

On Wed, May 23, 2012 at 4:10 PM, asif saeed <asif.lse2_at_[hidden]> wrote:

> 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