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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk