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

From: Michael Caisse (boost_at_[hidden])
Date: 2008-08-16 17:54:18

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*.
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. It is not uncommon to call the stimulus
a token or a message consisting of the stimulus and data. Often the state machine "method" 
operating on the stimulus is called a tick or clock.

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. 

>> 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. 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.
Perhaps I am missing something. Maybe we are not talking about event driven
state machines? I am happy to be shown something else.

Best Regards -
Michael 

-- 
----------------------------------
Michael Caisse
Object Modeling Designs
www.objectmodelingdesigns.com