Re: FSM Review Announcement

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)
>>>>> 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?

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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost