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

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-08-17 16:12:15

Sorry to jump in, but...

On Mon, Aug 18, 2008 at 3:55 AM, Andrey Semashev
<andrey.semashev_at_[hidden]> wrote:
>> 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.

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.

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.

This is by no means a complete review, but this is more to give
perspective as to the expectations are with regards to something as
fundamental (and useful) as a finite state machine implementation.

HTH

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.