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

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-17 16:42:02

Dean Michael Berris wrote:
> Sorry to jump in, but...
> 
> On Mon, Aug 18, 2008 at 3:55 AM, Andrey Semashev
> <andrey.semashev_at_[hidden]> wrote:
>> 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.
> 
> I might digress a bit, but you can (and most efficiently should)
> implement random number generators using a non-deterministic finite
> state machine. For example, generating a stream of random bytes can
> (and should, for efficiency purposes, IMO) be implemented using a
> simple finite-state machine but the actual transitions performed are
> non-deterministic. This is useful for thread-safe implementations of
> an 'entropy source'. There are a lot more experts out there in this
> field who may know more than I do, so I'll stop there.

I'm by far no expert too, but I thought that the algorithm of random
number generation is quite defined. The source of entropy is usually
either an initial value of seed or some external non-constant value
(like system time, CPU temperature, remote seed provider or something
like that) which is used as input to calculate the next seed. Anyway,
the library does not prevent you from making such random transitions.

> For a generic finite state machine library (that wants to be part of
> the Boost Library), I think there ought to be a balance between
> efficiency and safety. For instance:
> 
> high efficiency, less "safety": disable check for nullness, state-ful-ness
> high efficiency, more "safety": enforce supported transitions at
> compile-time (class structure, see MPL approach)
> low efficiency, more "safety": check everything and throw for recoverability
> low efficiency, less "safety": check everything, throw on undefined,
> allow illegal state-changes
> 
> These may have to be controlled through either macro definitions or
> different classes (specialized through parametric tags) to allow users
> to choose which implementation they prefer.

I'm not sure I understand you correctly. There are nearly no places in
the library where correctness checks are needed (the only one I could
remember on spot is the dynamic state switching - an exception is thrown
in case if FSM tries to transit to a non-existing state in run time).
And I don't think that this additional "if" would matter anything in a
real-world FSM. In all other cases the invalid code just won't compile.

If you meant safety from the user's perspective (e.g. how the FSM should
react on unexpected input), then it's totally user's choice.