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

Hi Christophe, Thanks for your detailed reply. I think it's important that you add some sort of basic rationale of this sort to the documentation - you need to evangelise what you believe are the advantages of the library from first principles to its potential users. I'm just going to pick up on a couple of points, mainly because I don't know enough about UML to comment on the rest. Christophe Henry wrote:

- 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.

I'm not sure how true that is. To make this concrete, let me discuss the terminal emulator FSM that I described in the Boost.FSM review. This has one main event, "character received", that carries the character as data. There are a few other events such as "SIGWICH" (GUI terminal size changed by user). For most "character received" events in most states, the action is to insert the recieved character at the current cursor position and advance the cursor. When the "escape" character is received the FSM changes to another state in which the subsequent characters are processed differently. I would implement this something like: struct terminal_fsm { enum state_t { normal, seen_escape, ... }; state_t state; Screen screen; Position cursor_pos; void character_received(char c) { switch (state) { case normal: switch (c) { case escape: state = seen_escape; break; .... more special characters like tab, newline etc .... default: screen[cursor_pos] = c; ++cursor_pos; break; } break; case seen_escape: switch (c) { case 'H': // say esc H = 'home' cursor_pos = 0; break; .... lots more escape sequences .... } state = normal; break; } } void sigwinch(int rows, int cols) { screen.resize(rows,cols); // it would be a better example if this did something depending on // the state; use your imagination... } }; This is O(1). Of course a difference is that it has different entry points for the different events. This doesn't seem unreasonable to me, but if you wanted a single entry point you could do something like: struct character_received_event { char c; }; struct sigwinch_event { int rows, cols; } void process_event(const character_received_event& e) { .... void process_event(const sigwinch_event& e) { .... Now you can call process_event() with events of either type. How would you do this with MSM? Something like this presumably: row < normal, character_received_event, seen_escape, none, &is_escape_char >, row < normal, character_received_event, normal, &insert_at_cursor_and_advance >, row < seen_escape, character_received_event, normal, &cursor_home, &is_H >, row < seen_escape, character_received_event, normal, none >, row < any, sigwinch_event, unchanged, &resize_screen > (I'm guessing that the un-guarded row applies when none of the guards match for a particular state-event pair, and presumably there is some way of matching any state as in the last row.) When this is extended to include all the other special characters and escape sequences, you'll have lots of rows that have the same state-event pair but different guards, each testing the character in the character_received_event for a particular value. It looks to me as if it will do this in O(N), not O(1). Or is there some other way of doing this?

And if you want to implement all these features in a switch/case, your code will quickly become terrible. You'll have to issue guidelines on how to implement them, each developper will have to redo the same again and again with the corresponding flow of bugs (what if I forget a "break"? Uh oh) and low productivity (not even talking about documentation).

C++ provides many ways to shoot yourself in the foot, as we all know. I am reminded of the section in the C++ FAQ that says, paraphrasing: Q: Java has the "final" keyword that makes it impossible for a subclass to override a method. How do I do that in C++? A: Write a comment that says "Do not override this method in subclasses". If that doesn't work, write a comment that says "If you override this in a subclass you will be fired." That's not to say that anti-foot-shooting is a bad thing. I use boost::noncopyable a lot, for example. In my experience of implementing state machines, I have not encountered the "terrible" code that you imagine (or "spaghetti" and Andrey described it in the FSM review). This may be a matter of taste: one person's spaghetti is another's... err... noodles?

Do we agree that this proves the need of a library?

I can see that some believe they need a library to do this; personally I might choose not to use it, but that shouldn't bother you (and doesn't suggest that it should not be in Boost). You are welcome to try to convince me that it has benefits that I have not yet seen.... Regards, Phil.