Boost logo

Boost :

Subject: Re: [boost] [MSM] Comparison with ad-hoc FSM implementation
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2009-12-09 09:18:35

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.


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


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



Boost list run by bdawes at, gregod at, cpdaniel at, john at