Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-11 14:11:29

on Mon Aug 11 2008, Andrey Semashev <> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at