on Mon Aug 11 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
- States are not an enum values but classes that may have a common virtual base, which allows to have state-specific and shared data in the FSM. The events are processed in states. I'm not sure that isn't overkill. In our implementation you are free to add any data you like to the FSM and use it in your transition (member) functions.
Your approach doesn't allow to separate state-specific data from the common data.
Yes, but in your approach the common data can't persist across state transitions. Is that not a serious limitation?
Why? It does persist as long as the FSM persists. All states and their base classes are constructed and destroyed with the FSM and never in the middle.
I'm confused. If states 1 and 2 have associated data of types A and B, the fact that A and B are both derived from C does not mean that there is only one copy of the base class... or are you doing something special to have states 1 and 2 share a single object of type D derived from A and B? [Please keep in mind that I'm not trying to say that the Book's FSM is better than the one in your library. It's clearly more limited.] -- Dave Abrahams BoostPro Computing http://www.boostpro.com