Hi Andrey, I thought I'd clarify a couple of points below. On Fri, 08 Aug 2008 11:55:30 -0500, Andrey Semashev <andrey.semashev@gmail.com> wrote:
My implementation has similarities to player2.cpp, however, there are significant advantages in Boost.FSM. - The library does not take addresses of user's functions, which allows to use templates and simplifies overloading. - States are not an enum values but classes that may have a common virtual base, which allows to have state-specific and shared data in the FSM.
Enum- vs. class-based states *per se* is a relatively minor aspect of the MPL's FSM example. You can have it either way [1]. In fact, earlier version of the example does use (non-polymorphic) classes to represent states: http://svn.boost.org/trac/boost/browser/trunk/libs/mpl/example/fsm/player.cp... Our derivative version here at work allows for state-specific data.
The events are processed in states.
This one, however, is IMHO the biggest difference between the approaches.
- States support enter and leave handlers.
Along with other niceties such as state invariants, this comes for free once you decide to go with the class-based states (the version we use at work has these as well).
There is also a reset method that allows to clear the states and silently transit to the initial state.
[1] Obviously, class-based states have a higher runtime overhead. -- Aleksey Gurtovoy MetaCommunications Engineering