From: David Abrahams (dave_at_[hidden])
Date: 2008-08-11 14:11:29
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)
>>> 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
[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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk