Johan Nilsson wrote:
"Topher Cooper" <topher@topherc.net> wrote in message news:EB688081-B031-11D8-BA4A-003065841348@topherc.net...
Hi:
[snip]
A particular mechanism (C++ constructor/destructor behavior) having been identified as being *analogous* to a desired behavior (entry/exit actions in an fsm), was then strictly identified with the same, and used to implement it.
Well stated. I agree with many things you mention in your posting, and in particular to this.
Please finish reading Topher Cooper's post. In it, you'll find the answer to:
Everything is possible. The question is: What exactly is the advantage? What are the use-cases?
Library user wants to keep his state alive during the entire fsm lifetime ;-)
The argument is that the "state" is not a FSM state. It is an object that represents the condition of an FSM state being active. This condition is regarded as a resource, and RAII is applied to manage it. You can't "want to keep the object alive", because that would mean that the FSM state is always active. It's similar to your wanting to keep a mutex lock alive. Simon Meiklejohn wrote:
On the subject of Constructors/destructors for state entry/exit-
A consideration is that the state object also gets deleted on shutdown (or deletion of the FSM), which is not a state-transition event as such.
The argument is that the FSM being in a particular state is a resource, and if the FSM is destroyed, this resource must be released (because the non-existent FSM is no longer in this particular state). It corresponds to real world cases where a particular state being active may be tied to physical resources being held, for example the pump being switched on. That's how I understand it, anyway, all based on cursory reading of the thread. ;-)