Re: [boost] Proposal to add a Boost.FSM library

From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-01-03 15:11:21

Hello Alexander,

Wednesday, January 3, 2007, 9:46:16 PM, you wrote:

> Andrey Semashev wrote:
>> Although I was pointing out something different in my previous post,
>> returning a state or a reference to it has one major drawback. What
>> "on_process" should return if the next state depends on the event
>> contents?

> It would return variant<State1&, State2&, /* ... */ >. Visual
> representation of FSM would be fuzzy but it still better than no
> visual representation at all.

The "variant" has a limited set of possible types and it takes some time
to dispatch the real type of the object it stores. Besides, I'd like to
keep the ability to return something useful for the user from
"on_process".
IMHO, transition maps exist to make FSM transitions visible at the
first glance. No need to involve event handlers into this and take
away several useful features by this, such as return values and template
event handlers, and add these "id< ... >" arguments on top of that.

>> Besides, when returning a reference, where should the state
>> object be stored?
> For example, in a state machine object.

>> It may not be the current state member since it is
>> destroyed on state exit. So, once again, it may only be a member of
>> some outer state.
> Not necessarily. It may be a member of a state machine.

Actually, it's the way Boost.FSM is implemented except that it doesn't
allow to access one state from another and therefore ensures
encapsulation.

-- 
Best regards,
 Andrey                            mailto:andysem_at_[hidden]