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

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-17 07:37:34

David Abrahams wrote:
> on Sat Aug 16 2008, "Christian Holmquist" <c.holmquist-AT-gmail.com> wrote:
> 
>> However, nothing stops me from simply
>>> calling the set_address method which will result in either a Default or
>>> Configured state.
>>> He intentionally described that as undefined behavior.
>> Sorry for breaking in, I'm no expert on state machines at all but.. isn't
>> the goal of expressing a FSM by the aid of the proposed to library to
>> minimize the chance of undefined behaviour? 
> 
> *The* goal?  There are lots of potential reasons one might want to use a
> library.  In general, a library that allows a fairly direct expression
> of the FSM as described in its "native" language (OK, maybe graph
> diagrams won't work, but you could use state transition tables) should
> lead to code that is more correct and maintainable.  

David, you won't argue that every tool has its purpose, will you? I'm
sure it is possible to put a nail in the wall with a microscope, but
it's not the microscope's flaw that it's too fragile for that. State
machines, as I see it, are meant to define an object behavior, IOW
reduce the amount of undefined behavior. It is pointless to use them to
implement undefined behavior.

> I find the code written using the proposed library rather procedural in
> nature (rather than declarative), thus the OP's comparison is very apt
> from my point-of-view.  The hand-rolled code actually looks clearer and
> more direct to me.

Please, have a look at my reply to Phil. I've attached a code snippet
with a transition map. Does that look more declarative?

> Note that when the OP wrote "undefined behavior" I don't think he meant
> that the C++ standard would say it was undefined; rather that his state
> machine implementation was not going to promise any particular results
> on invalid inputs.  Avoiding undefined behavior is certainly not always
> the primary goal of using a library.
> 
>> If the OP's state machine doesn't guarantee its valid state, 
> 
> It guarantees a valid state as long as the inputs are valid, just as
> 
>    x / y
> 
> or
> 
>    *p
> 
> do, where x, y, and p are primitive types.  Most libraries I know have
> similar contracts.

I don't fully agree with this. On the one hand, yes, most libraries rely
on the valid input and this is "the right thing". On the other hand,
FSMs are often used in domains where input is not always valid (parsers,
protocol clients, GUI and so on). And FSMs are one of the tools to
define behavior even in face of invalid input. It's the difference
between a good and bad application: the good one doesn't blow up the Sun
if you push the wrong button. :)