"Peter Dimov" <pdimov@mmltd.net> wrote in message news:009a01c444ac$a8587690$0600a8c0@pdimov...
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.
Assuming I had the same mental definition of a "state" as the library in its current incarnation, yes. I'm expressing myself too ambiguosly, with the only excuse getting a bit tired of the discussion. If it's not a state, as in FSM state, why call it a state? It's already been a source of confusion (and not only for me). I did actually read Topher Cooper's post, but obviously skimmed the important parts. Now I've given it the time it well deserved. Perhaps renaming "state" to "state_activation" would clear things up. However I'm still not convinced that states (state objects corresponding to FSM states) should be non-existing in the library. I'm probably too tired to mention this but: how about creating state_activations with state objects as ctor parameters? Regards // Johan