Boost logo

Boost :

From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2008-08-28 23:01:39


My review appears here with an attached cpp file implementing four
approaches (not compiled): a manual nested switch/if function, the TMP
book's mpl state table, boost.statechart, this FSM library.

> What is your evaluation of the implementation?
> Did you try to use the library? With what compiler? Did you have any
> problems?

Didn't download the library code, just read through docs and tried to
implement a simple state machine comparing other approaches.

> What is your evaluation of the potential usefulness of the library?

I think there are many applications for a lightweight, expressive FSM
library in areas not typically using FSM's such as mouse event processing,
filtering/transforming iterators,...

> What is your evaluation of the design?
> What is your evaluation of the documentation?

My view of the design is limited to what is described in the documentation.
I was a little dismayed that some of the basic features that I needed are
considered Advanced features such as sharing state and accessing the current
state from outside the state machine. These are very easily accomplished in
the TMP and StateChart libraries. The section on accessing state is not
sufficient for me to determine which state the fsm is in between calls to
process(). The data sharing approach between sibling states using a virtual
base class is perplexing... there's no discussion of just what is the
structure of the state machine. There is a lot of repititious boilerplate
required relative to other libraries. There is a mixing of the transition
"structure" in the procedural code which is better separated in the
transition table approach. The FSM transition map may improve upon this, but
I started getting lost in the description.

Documentation terminology drifts from the familiar "transition", "table",...
introducing new terms "switch_to" and "transition map" without describing
how/why they are different from the standard terms. The documentation seems
to become less clear as the interface becomes more complex and verbose. The
StateChart library addresses much of the same issues but always seems to
remain comprehensible and keeps the reader grounded in familiar concepts
while introducing new ones. I don't seem to be able to grasp the overall
design concepts of FSM from it's documentation.

> How much effort did you put into your evaluation? A glance? A quick
> reading?
> In-depth study?
> Are you knowledgeable about the problem domain?

I spent several hours reading the docs and putting together the attached
example using the 4 different libraries/implementations applying them to a
"paraphrased-from-an-in-production" use case. The state machines are used to
iterate through an input stream of integers, extracting triplets of integers
that are even or odd. Odd integers appearing within a even triplet are
skipped, triplets of odd integers are extracted when they occur between even
triplets. The transition table in the attached cpp file clearly depicts the
UML state chart upon which the example is derived.

I've spent several years developing software that integrates
Matlab/StateFlow generated code with hardware in the loop systems. So I'm
familiar with many of the concepts.

> Do you think the library should be accepted as a Boost library?

No. I'd prefer that the performance and missing functionality be added to
improve the existing StateChart library, and/or a true transition table
approach be provided ala the TMP book's transition table. I dislike FSM's
verbose interface along with it's procedural leaning paradigm.

Jeff




Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk