From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2008-08-17 18:25:05
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.
But don't worry if you disagree; this is unimportant. The intention of
my original message was to suggest that your library seems to add a lot
of verbosity to my implementation, without much obvious benefit. I
would like to be convinced otherwise, preferably through examples.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk