6 Aug 00:02
Re: FSM Review Announcement
From: Chris Knight <cknite <at> gmail.com>
Subject: Re: FSM Review Announcement
Newsgroups: gmane.comp.lib.boost.devel
Date: 2008-08-05 22:02:02 GMT
Subject: Re: FSM Review Announcement
Newsgroups: gmane.comp.lib.boost.devel
Date: 2008-08-05 22:02:02 GMT
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 areNested 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
_______________________________________________
Unsubscribe & other changes:
RSS Feed