Christophe Henry wrote:
Hi Phil,
switch ((state<<8) | event) { case (Stopped<<8)|play: start_playback(); state=Playing; break; case (Stopped<<8)|open_close: open_drawer(); state=Open; break; etc. etc.
The greatest advantage of this ad-hoc style is that it is readable by anyone who has even the most basic understanding of C++ without the need to learn a new library, and its exact behaviour is immediately evident. It is also likely to compile and run quickly.
I used to do that, but found someone reordered the state assignment before the function calls, and one of the functions was dependent on the value of state. Having a truly declarative State Transition Table disallows accidentally changing the above procedural statements sequencing. It also helps reinforce the FSM mindset, which showed the aforementioned function should have been represented as additional states and events. As to whether the above is "immediately evident" it is not so evident to me. I need to interpret a very generic "switch" and "enum" facilities and intuit the semantics from the variable names that it's implementing an STT. Whereas in MSM and it's predecessor the TMP book's STT example declare a type ala: struct transition_table : boost::mpl::vector41 ... To me this is much more evident, and is analogous to using std::copy, or std::accumulate instead of a for-loop... the 1st word of the statement tells me the full semantics of whats to come. [snip]
- events containing data. In your case, you are more or less forced to choose between the O(1) (which you did) and forgo event data or the O(n) (chosen by Rhapsody) at a speed cost. Metaprogramming techniques allow us a O(1) with event data.
This was an important one for me in handling UI selection with an FSM that replaced lots of client code with a single shared state machine processing events such as pressed_item, shift_pressed_item, over_item, release_item... Since these are types, they can have multiple constructors to handle specific needs and be polymorphic for additional design expression. I've also found that using enums in the OP's fashion quickly degrades into a redundant pseudo-type-system increasing cognitive and maintenance overhead while decreasing type safety. [snip]
Of course, like always, developers use only 20% of all UML features. But it's never the same 20%, so what you need depends on your "coding" style.
Exactly!!! So now we'll have a standard place(or two, including the StateChart library) where all developers can look for documentation on how to address FSM issues in an accepted and consistent way. [snip] Jeff