Re: [boost] FSM Review Announcement

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-10 18:32:14

on Fri Aug 08 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:

> David Abrahams wrote:
>> on Tue Aug 05 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
>>
>>> David Abrahams wrote:
>>>> on Tue Aug 05 2008, Chris Knight <cknite-AT-gmail.com> wrote:
>>>> I don't know if you've seen the FSM examples from "C++ Template
>>>> Metaprogramming" or not.  It would be interesting for this library's
>>>> documentation to explain its advantages over that approach (I can see
>>>> some from here already).
>>> No, I don't have that book.
>>
>> For your perusal:
>>
>> http://www.boostpro.com/mplbook/examples/player.cpp
>> http://www.boostpro.com/mplbook/examples/player2.cpp
>
> Thanks for the info. I guess I'm not the first one who came up with
> such approach. :)
>
> 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.

Huh?  The member function pointers involved in our code are all
compile-time constants, and thus work very well with templates (in fact,
they are passed as template arguments).

> - 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. The events are processed in states.

I'm not sure that isn't overkill.  In our implementation you are free to
add any data you like to the FSM and use it in your transition (member)
functions.  

> - States support enter and leave handlers. There is also a reset
> method that allows to clear the states and silently transit to the
> initial state.

Yeah, that's a real advantage.

> - Other minor things, like auto-generated state names, dynamic handler
> for unsupported events, 

Our design lets you make the handler static or dynamic as you please.

> thread-safety issues, etc.

Not sure what issues you have in mind.

> I'd love to put a full comparison to the library documentation, but I
> feel this would be not... fair (for the lack of a better word) since I
> didn't read the book and only seen a couple of examples.

What you're seeing is a little more than everything the book does with
FSMs, so I think it would be fair.  More importantly, it would supply
people familiar with the book with a useful frame of reference.  Since
the book's example was never meant to be more than a (very usable) toy
for demonstrating some principles of DSLs, I wouldn't worry about trying
to "be fair."

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com