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