From: Alexander Nasonov (alnsn_at_[hidden])
Date: 2007-01-03 15:45:15
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
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk