From: Andrey Semashev (andysem_at_[hidden])
Date: 2006-12-31 17:46:34
Sunday, December 31, 2006, 10:43:37 PM, you wrote:
>> 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.
-- Best regards, Andrey mailto:andysem_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk