Re: [boost] FSM Review Announcement

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2008-08-18 23:27:52

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_at_[hidden]> 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.cpp

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