Dean Michael Berris wrote:
Sorry to jump in, but...
On Mon, Aug 18, 2008 at 3:55 AM, Andrey Semashev <andrey.semashev@gmail.com> 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.