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

From: Andrey Semashev (andysem_at_[hidden])
Date: 2006-12-31 17:46:34

Hello Alexander,

Sunday, December 31, 2006, 10:43:37 PM, you wrote:

[snip]

>> Besides, nothing prevents you to access or modify this data from, say,
>> "Running on_process(id<1>, Initial, integral_c<event,Start>) const;"
>> handler which has nothing to do with neither Operational nor Running
>> or Paused states.

> I think it makes sense to support State&, reference_wrapper<State> and
> shared_ptr<State>. For example,

> // The framework should recognize a reference and act upon.
> Running& state_machine::on_process(
>         id<1>, Initial, integral_c<event,Start>) const
> {
>     // ...
>     return m_RunningInstance;
> }

> This approach has two advantages:

> 1. You control a construction of m_RunningInstance (Not sure that it's
> always a best choice than automatic state management)
> 2. You have a better control during processing, e.g. you may return an
> object from a pool of objects rather than using only one state object.

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? Besides, when returning a reference, where should the state
object be stored? 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.

[snip]

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