On Tuesday 05 August 2008 4:34:30 pm David Abrahams wrote:
I don't know if you've seen the FSM examples from "C++ Template Metaprogramming" or not. It would be interesting for this library's documentation to explain its advantages over that approach (I can see some from here already).
One other thing I'd like to see is an implementation of nested states. I once promised some people who needed that functionality that I'd extend our framework to support them, but was never able to figure out what their semantics are ;-)
Nested states would be nice. I looked through the "C++ Template Metaprogramming" book as another reference when developing our internal implementation. I didn't get too fancy in our own but some protocol's like FIX for instance has many, many dark corners. I would see nested states as simply a further restriction on the matching of the from state. This could provide further optimizations as a well designed transition table could reduce the set of states to match against. However, I'm not quite sure how that plays out in a design with the enter/exit state handlers, transition handlers, et al. The finite state machine I came up with for the FIX protocol was well over 50 transitions. I implemented ours so that the from state could be boost::any which acts acts like '.' in regexps and I suppose means our implementation should be renamed kmt::nfsm. It was a zero-cost implentation as it simply adds one last transition to each from state's action linked-list.I was able to get the transition list down to 22 with that one feature. Mostly all the different error conditions that you want to handle gracefully in a text protocol originally designed in the 1980's and still used by finance exchanges today. <sigh> The other feature that I'm not sure whether FSM supports or not is static registering of posted event types so as to skip around run-time double dispatching. I suspect any implementation that seeks to provide a simplified/speedier interface over StateChart should support that as well. Chris