[boost] Re: Re: Re: FSM library question

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-02-27 19:41:36

Jeff Garland wrote:
>> I guess you mean the increase in complexity compared to the
>> traditional ways of implementing FSMs (nested switch case, state
>> pattern, etc.). I think there's an increase only for small simple
>> machines, like StopWatch. I think there is a (sometimes dramatic)
>>  reduction of complexity for bigger (and more real-world) machines.
>
> I addressed what I meant by complexity in my response to Darryl. The
> thing is since we don't have an example of bad code that can be
> simplified by an fsm to compare agaisnt in the docs and we can all
> think of easier ways to write the StopWatch I worry that people will
> be put off.

The tutorial is primarily addressed to people who already have had 
exposure to FSMs (and also had to implement them one way or another). 
You are right, a beginner with only theoretical or even no prior 
knowledge about FSMs would probably shake his head before even following 
through the StopWatch example. I've spent quite some time thinking how I 
could also address newbies but have come to the conclusion that this 
would require a separate document at least as large as the tutorial.

> So I think the remedy is to just say that stopwatch is
> too simple to bother with fsm, but with bigger state machines there
> is significant advantage.

I will try to do that, in particular I'll try to explain more thoroughly 
the issues with global variables.

>> Currently there's no code generation and I doubt there'll ever be
>> such a tool (I personally wouldn't use it). IMHO, a reverse
>> engineering tool would be *much* more useful.
>
> Perhaps.  If there was an XMI (UML to fsm generator or another state
> definition language) it might be easy to generate.

I think that a graphical state chart --> code generator surely helps 
beginners to get started. It provides them with *skeleton* code very 
soon. However, the generated skeleton is unlikely to do anything useful 
(I expect the generated code to be similar to the one right before the 
"State-local storage" heading). To get the code to do something, the 
programmer needs to fill statements into the action bodies. To be of 
help after doing so, the generator needs to be pretty sophisticated. To 
me, this seems too much work for something that can just as easily and 
probably faster be done manually. Sure, the initial effort to get 
something to compile is a little higher without a generator, but only a 
little.

>> You usually make variables as local as you can (i.e. push them
>> towards innermost states as much as possible). There would be more
>> to say here but I'll be off soon. More on this later...
>
> Ok, good. I think this sort of discussion would be useful in the FAQ
> or somewhere in the docs.

Agreed. BTW, I think Darryl's take on variable scoping and heuristics 
hit the nail on the head.

Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.