Andrey Semashev wrote:
Wednesday, January 3, 2007, 9:46:16 PM, you wrote:
It would return variant<State1&, State2&, /* ... */ >. Visual representation of FSM would be fuzzy but it still better than no visual representation at all.
The "variant" has a limited set of possible types
So does any state machine - it has a limited set of types ;-)
and it takes some time to dispatch the real type of the object it stores. It a resonable price for the flexibility.
Besides, I'd like to keep the ability to return something useful for the user from "on_process".
IMO, it doesn't outweight an ability to have a transition table available at compile-time.
IMHO, transition maps exist to make FSM transitions visible at the first glance. No need to involve event handlers into this and take away several useful features by this, such as return values and template event handlers, and add these "id< ... >" arguments on top of that.
An ability to define one function for transitions from several states is more important than template handlers. I agree that id<...> is not convinient. I'd be happy to get rid of it.
Actually, it's the way Boost.FSM is implemented except that it doesn't allow to access one state from another and therefore ensures encapsulation.
I couldn't build a sample program neither on gcc 3.4.6 nor on Intel Linux 8.1 so I can only guess that dynamic_cast<OtherState*>(this) would access OtherState from *this state. -- Alexander Nasonov http://nasonov.blogspot.com Nothing is more obstinate than a fashionable consensus. -- Margaret Thatcher -- This quote is generated by: /usr/pkg/bin/curl -L http://tinyurl.com/veusy \ | sed -e 's/^document\.write(.//' -e 's/.);$/ --/' \ -e 's/<[^>]*>//g' -e 's/^More quotes from //' \ | fmt | tee ~/.signature-quote