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

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-17 01:35:23

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.  

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.

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.

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