Phil Endecott wrote:
Andrey Semashev wrote:
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.
An environment that makes guarantees about how it will or will not behave is not generally a completely deterministic environment.
Example: say I'm receiving UTF-8, and I'm guaranteed by the sender that it's valid UTF-8. I still need to track the state of the stream as I process the bytes, even though I'm going to allow undefined behaviour (either in the C++ language sense, or in some other sense) if those bytes are invalid. This particular problem could certainly be usefully expressed using an FSM.
Agreed. I admit, I didn't think about it.