From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-11 14:27:17
David Abrahams wrote:
> 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
> and B?
That's right, the library constructs a composite class that derives from
all states. This allows states to virtually derive from a common base
and share its data between each other. This composite class is a part of
the complete FSM, so all states live as long as the FSM does. Switching
between states only calls enter/leave handlers in the states, which can
be used to initialize or clean the data in the state.
> [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.]
Yes, I understand that it's merely an example for the book.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk