Re: [boost] Re: Re: [prereview request][fsm]

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-05-28 07:09:40

Johan Nilsson wrote:
> "Topher Cooper" <topher_at_[hidden]> wrote in message
> news:EB688081-B031-11D8-BA4A-003065841348_at_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. ;-)