From: Andreas Huber (ah2003_at_[hidden])
Date: 2003-06-02 07:17:25
> >Unfortunately, I don't have much experience with anything else
> than MS
> >compilers. I will try to port to gcc, but I'll probably need help
> >not-so-conforming compilers like Borland.
> I have experience with GCC, MS and Borland if you need help porting
Cool, I could probably use some help with the gcc-port in about a
month or so. Borland could follow.
> >void Pump::Start()
> > initiate< Idle >(); // ***** here *****
> Wouldn't this complicate the code that the programmer has to write,
> your version was simpler to implement. (Just my opinion).
True. After posting I realized that the current design already allows
you to hide the states in the .cpp file anyway. All that remains in
the .hpp is one forward declaration of the initial state. The above
approach is only necessary if you want to hide that as well. I guess
most people wouldn't bother.
> >Does the library/code generator you're currently using work with
> >polymorphic events? Is not having polymorphic events a showstopper
> for you?
> >If yes, I would be interested in a as-real-world-as-possible
> I'm not sure on this, but would Windows-based code that redirects
> events to
> a Window class be a polymorphic event, e.g.
> class WindowBase
> virtual void Paint( win::api::DC & hDC );
> // ...
> class MyGUIWindow: public WindowBase
> void Paint( win::api::DC & hDC ); // custom window
> Not sure how you would integrate this with a FSM though!
AFAICT, WindowBase and MyGuiWindow objects are both state machines
producing different reactions for the same Paint event, which is
therefore not polymorphic.
A state machine supports polymorphic events, only if ...
- Events can derive from each other without restrictions (see
Bohdan's MouseEvent example)
- You can specify reactions for nodes as well as leaves of the event
inheritance tree. That is for MouseEvent, MouseDownEvent and
MouseUpEvent in Bohdan's example.
Thanks for the feedback!