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

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-17 15:55:06

Phil Endecott wrote:
> Andrey Semashev wrote:
> 
>> IMO, undefined behavior usually is a design flaw, and this case is
>> clearly one of the "usual" ones. Otherwise, like I said, you don't need
>> FSM, because its whole purpose is to _define_ the behavior.
> 
> I disagree.  If I have a guarantee of how the environment will behave it
> is unnecessary to check it, except perhaps in some sort of debug mode. 

Agreed. But in such a case, do you need an FSM in the first place? If
you have the guarantee that function A will always be called before
function B, you will simply rely on it and assume that while in B, A has
already been called.

> Picking up on one of Dave's comments, do you put a test in every
> function that takes a pointer to test whether you have been passed a
> null?  Of course, when the behaviour of the environment is not
> guaranteed then I do need to check.  If the scope of the proposed
> library is intended to be limited to applications where the environment
> is untrusted, please make a note of that in the documentation.

There's nothing in the library that prevents you from using it in a
predictable environment. You certainly can implement "undefined
behavior" with the library as long as you can express it in C++. I just
don't see the point of using FSM (as a concept, not the particular
library) in such a case.