Re: [boost] Preliminary submission: Finite State Machine framework

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2003-06-01 00:04:34

Hi Andreas,

[...]

> An attempt at an easy-to-use FSM library that supports 
> well-maintainable and code-expressive machines of almost any size and 
> does not require a code generator can be found in the fsm directories 
> in the boost-sandbox and here:
> 
> http://groups.yahoo.com/group/boost/files/FSM/
> 
> There is comprehensive tutorial and rationale documentation. All code
> has been tested with MSVC7.1 and boost 1.30.0
>
> Features include:
> 
> - Straightforward transformation from UML state chart to executable 
> C++ code and vice versa
> - Comprehensive UML semantics support:
>    - Hierarchical (composite, nested) states
>    - Orthogonal (concurrent) states
>    - Entry-, exit- and transition-actions
>    - Guards
>    - Event deferral
> - Error handling support
> - Full type-safety
> - State-local storage
> - Customizable resource management

It's very exciting to see a FSM framework coming close to the formal 
submission stage!

IMO state machines are something that every software engineer should
be famililiar with, because no matter what kind of software you write,
if there is any significant amount of logic in it, FSMs can offer you 
the means to structure and simplify it, improve its adaptability to 
changes, and ultimately make it more understandable, robust, and 
easier to maintain, debug, and verify. That is, if you have a tool at 
hand that makes implementing FSMs as easy and enjoyable as it should 
be. 

So, while here at work we have developed an in-house technology
that achieves that goal for small-to-medium FSMs (the first prototype
of which is outlined in the MPL paper), I am really looking forward to 
studying experts' work on the subject.

Well, meanwhile, besides the above, my first comment is going to be 
really minor - I browsed over the tutorial (which looks great!), and 
although I am sure you know it, I thought it would be worth to point
out that the 'public' specifier is redundant when the derived class 
is declared as 'struct'; if you omit those, the examples' syntax would
become even more DSL-like (== better :).

Aleksey