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.