
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

Hi Jeff Thanks for your review! Jeff Garland wrote: [snip]
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.
One example of an embedded system where I think this library wouldn't cause any noticeable overheads is a digital camera, which usually needs to have a rather fat processor for fast jpeg encoding. The FSM inside such a camera only needs to have reaction times in the 100 millisecond range (good enough for the human pushing the buttons). I think there are many other such systems. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (2)
-
Andreas Huber
-
Jeff Garland