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@mail.ru