On Dec 5, 2009, at 4:25 PM, David Abrahams wrote:

On Dec 6, 2009, at 1:08 AM, Christophe Henry wrote:

...

...

...

Repeating: the MSM/Statechart overlap in features and interface is quite unique to Boost.

They definitely overlap in features and also in intent, but my understanding is that the interfaces are vastly different, and that's an important distinguishing feature. Am I missing something?

No you aren't.

Then, for the record, I would give David Bergman's opinions in this thread more weight if he would retract his claim that each has a "virtually identical … interface."

That statement of mine was not correct, in isolation. *Part* of the interface is; I spelled it out in another post.

His other points seem quite valid on the face of it, but this one seems completely off target, and is likely the cause of the heated response he has received.

Yes. I understand that. I clarified in another post what I meant, and there used 'abstraction'; the API is not identical - except for the execution part of the machine where the they (almost) are - the main differences being: 1. In Statechart, you define the machine outside-in (machine before sub machines before states) while in MSM you often do it inside-out (states before machines) 2. In Statechart, the definition of a state is coupled to the machine in which it resides while in MSM the state can be defined totally in isolation of the machine, and, thus, reused in other machines 3. In Statechart, the transitions are coupled to the from-state, and defined therein, whereas in MSM, the transitions are coupled to the machine itself; this makes it a bit tricky to reuse a state in Statechart 4. In Statechart, CRTP is used for most definitions, whereas in MSM, it is only used for the machines. 5. MSM has eUML, which I have *not* used, to simplify the machine specification. A translation from a Statechart program to an MSM variant would look something like this (with a machine containing two states and one transition and associated action): [Statechart code] struct Event : event<Event> {}; struct State1; struct State2 struct Machine : state_machine<Machine, State1> { void action(const Event& evt) {} }; struct State1 : simple_state<State1, Machine> { typedef transition<Event, State2, Machine, &Machine::action> reactions; }; struct State2 : simple_state<State2, Machine> { }; Machine fsm; fsm.initiate(); fsm.process_event(Event()); [MSM code] struct Event {}; struct State1 : front_state<> {}; struct State2 : front_state<> {}; struct Machine_ : state_machine_def<Machine_> { void action(const Event& evt) {} typedef mpl::vector< row_a<State1, Event, State2, &Machine_::action>

transition_table; }; typedef state_machine<Machine_> Machine;

Machine fsm; fsm.process_event(Event()); It is up to others to judge whether these interfaces are similar. The big deal in a translator from Statechart to MSM code would be to move the transitions out of the state definitions (the individual 'reactions') and gather those rows in a big table (the common 'transition_table'), inside the machine definition, and getting rid of the CRTP, and finally creating a "back end" version of the machine definition (or "front end" version.) I could create a translator in XSLT (from a gcc-xml output) for these simple cases... Again, I am sorry that I used the word "interface" there where I actually intended it in a quite abstract manner, as in "how to deal with the (common...) notions." /David

On Dec 6, 2009, at 5:04 AM, Andreas Huber wrote:

...

2. In Statechart, the definition of a state is coupled to the machine in which it resides while in MSM the state can be defined totally in isolation of the machine, and, thus, reused in other machines

FWIW, in Statechart you can decouple a state from its machine by making it a template.

Funny you wrote that, because I have done exactly that! But found it to be a bit ad hoc. David