Re: FSM Review Announcement

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