
Hi,
I haven't yet looked at MSM. However, I do wonder if the activity/state diagrams
generated from MSM based code would be convertible to equivalent sequence
diagrams. In other words, I want to know if MSM does indeed create object instance
and whether it creates those instances on heap, etc. In short, I am interested in the
performance aspect. I have a scenario where I have two state machines - basically,
protocols for the trading domain - and I am supposed to map one protocol to another
and vice versa - that is, develop a message broker. I am thinking about designing a
generic solution that could be used to map any protocol (all messages along with
their behavior) to any protocol based on the grammar - the message strings, their
sequences, etc. Can I use MSM for this kind of a problem? I did write something
like this for a client a long time back but it would take me quite some time if I jump
into doing that again. That does make think if Boost MSM (or StateChart?) offers a
faster solution.
Thanks in advance,
-Asif
Hi, MSM creates all states on the stack for better performance. Actually, msm does not know the word "new" ;-) The only things which can use the heap are the queues (which you can customize / disable). What Joel wrote is also correct: all states are created on the stack upon fsm construction and stay around until destruction, the state machine is copyable (and even serializable/deserializable, which might help if you want to send them as a string along the message). I'm not sure I fully understand your problem but as a small note, state machines and sequence diagrams are not equivalent (sequence diagrams do not have the "specification" capability). What you also need to know is that with msm, a state machine structure has to be known at compile-time, you cannot design it at run-time depending on a concrete message data. Something like "if(...) fsm.add_transition(...))" is not possible. HTH, Christophe