[boost] FSM review

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-03-05 16:31:07

I'll start my review with the conclusion:  I recommend fsm be accepted into
Boost -- thanks to Andreas for his excellent contribution. FSMs apply to a
broad range of software products and the proposed library would simplify the
implementation of many of them.

* What is your evaluation of the documentation? How easy (or hard) it is to
understand library features? What can be improved?

Overall I think the documentation is good, although I think the tutorial code
be improved slightly by carefully illustrating the 'boilerplate' part from
where the user would add code either to a machine or to a state and the design
tradeoffs that would drive one to this approach (we had some discussion of
this earlier and it might be better in the FAQ then in the tutorial).

* What is your evaluation of the design? What features are supported better by
alternative FSMs? What could be added (or removed) from the library?

Overall the library is well thought out and supports a wide range of essential
features for building fsms. 

* What is your evaluation of the implementation?

I spent a few minutes browsing the implementation.  In general the code is
written clearly and understandably -- even though I couldn't possibly
understand the full context of the code or truly evaulate the implementation.
 There is also a large number of tests already written which should help with
porting / regression testing.  Overall the implementation appears to be up to
usual boost standards.

* Are there performance bottlenecks? Does the library design fit requirements
of real-time systems? How is it useable for embedded systems? Is the
documentation clear on performance tradeoffs?

No opinion on this except that there is good documentation of the performance
implications of using the library.

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

*Can you compare this FSM to other implementations?

Most other FSM implementations are code generators of one sort or another. 
For example: <http://smc.sourceforge.net>.  Being a pure library (and a header
library as well) makes the current proposal very attractive. No new tools to
required to take advantage of the capabilities.

* Did you try to use the library?  With what compiler? Did you have any problems? 

Yes - gcc 3.3.1 under dev-c++.  No problems.  I modified the tutorial examples
to try and understand what a user would need to learn to use the library.

*Do you have tips for better support of older compilers? What are possible
portability problems?

I think Andreas should ignore older compilers.

* How much effort did you put into your evaluation? A glance? A quick reading?
In-depth study?

A few hours.  I also looked at the library about a year ago and followed list
discussions over the last couple years.

* Are you knowledgeable about the problem domain?

I'm quite famaliar with FSM for software design having first studied them in
college over 20 years ago.  I've also worked on projects that use state
machine compilers.

*The library documentation contains few not yet solved issues (name,
separating the library into two parts, exception handling). What is you
opinion here?

1.  Library name -- Obviously boost::fsm is not for everyone....

I think the library name is fine.

2. Two libraries in one: The library consists of two parts that could easily
be separated...

I'd leave the library alone for now.  More experience will show whether it
makes sense to split it.

3. Exception handling support: Several people have rightly pointed out that
the rationale for the exception handling support is too thin. 

The rationale seems good enough to me for now.  A more advanced paper would be
nice, but doesn't seem essential to using the library.

4. On some compilers (e.g. gcc), the asynchronous part of the library and most
of the tests currently cannot be compiled with RTTI turned off. 

This isn't a problem in my view as RTTI is a feature of C++.  While I
acknowledge that there are a group of folks that want to turn it off for
embedded work, I think if they are that concerned about performance they
probably won't use fsm anyway.  So the bottom line is I don't see that this is
a problem.

Jeff