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