Re: [boost] [fsm review] Comparison with ad-hoc FSM coding

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-16 19:47:47

on Sat Aug 16 2008, Michael Caisse <boost-AT-objectmodelingdesigns.com> wrote:

> David Abrahams wrote:
>>> Even an ad-hoc state machine implementation should have some type
>>> of "tick" or "clock" type method that takes a token or message
>>> (with or without payload).
>>>     
>> I can't picture what you have in mind here.
>>   
>
> What Phil described tracks state just fine; however, I wouldn't call
> it a *machine*.  

I suppose you'll explain why not here...

> State machines consist of states and transitions. Transitions are
> transversed upon some stimulus. The *machine* part of the state
> machine receives the stimulus and then causes the transition to a new
> state. 

Sure, I'm familiar with the abstraction.  So far his code meets the
definition.

> It is not uncommon to call the stimulus a token or a message
> consisting of the stimulus and data. 

OK, or an "event," as I've heard it.

> Often the state machine "method" operating on the stimulus is called a
> tick or clock.

Well, sure, you could make all the member functions overloads of the
same member function taking different event types (as does the one in
C++TMP), and then it looks more like there's only one "tick" or "clock"
entry point.  However, the effect is nearly the same even though the
abstraction is slightly weaker.  The specific function being called is
chosen at compile-time, and that's perfectly adequate for many
applications.  It's true that in some designs events can be queued or
otherwise need to be dispatched dynamically, but there's no need to make
all FSM users pay for dynamic double-dispatch, and it's easily handled
in a layer on top of the statically-dispatched design.

> What was described allows the user to take any transition at any time
> by invoking a method which then stores the new state. It lacks a
> concept of stimulus causing a transition.

I disagree.  Each entry point called can be viewed as a stimulus.

>>> So, while your ad-hoc machine will track a state if the methods are
>>> called in a valid order, I'm not sure I would refer to it as a
>>> state machine.
>>>     
>> I would. It's certainly no less valid than the one presented in
>> C++TMP.
>   
> I apologize, I am not familiar with that presentation. 

I'll re-post the links:

http://www.boostpro.com/mplbook/examples/player.cpp
http://www.boostpro.com/mplbook/examples/player2.cp

Please keep in mind that these are simple frameworks designed to
demonstrate how template metaprogramming can be used to build
domain-specific languages, and not intended to be complete FSM
libraries.  That said, I've heard of several people picking up this
design and using it successfully when they needed to build an FSM.

> State machines are not foreign to me. I commercially offer my own UML
> (Real-time Object Oriented Methodology ROOM) package that takes a
> graphical representation through code generation and targets many OS's
> or bare metal. I extensively use state machines in FPGA
> implementations.

I bow to your greater depth of experience with FSMs.

> Perhaps I am missing something. 

Or perhaps I am.

> Maybe we are not talking about event driven state machines?

What's the difference between an "event" and a "token" or "message?"

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