Rob Stewart wrote:
> >>> Is it? In the current design the state machine object owns the
> >>> state objects (it does so for good reasons). How can you destruct
> >>> the state machine object without destructing the state objects
> >>> (and thus inevitably also exiting them and terminating the state
> >>> machine as a result)?
> >>
> >> You're still collapsing separate concepts.
> >
> > The current implementation does. I don't think I did with the above
> > reasoning.
> 
>  I read "in the current design...how can you destruct [sic] the
>  state machine object without destructing [sic] the state objects
>  (and thus...exiting them,..." as clearly linking the ideas.
>  (Points 2 and 4, above.)

I think you misunderstood why this particular discussion stared:

Andreas Huber wrote:
> > Furthermore, it
> > seems as though, if you want that behavior, it's trivial to get it by
> > wrapping the FSM in a derived class whose destructor finalizes the
> > state machine.
> 
>  Yes, but only at the cost of making the current interface (and
>  implementation) more complex (we'd need to have at least a separate
>  exit() function, right?).


IIRC, with "that behavior" Dave meant that a state machine is terminated on
destruction. The rest of the argument then is about whether an interface
change is necessary or not (and I still don't see how it could possibly be
done without introducing exit()). But this isn't relevant anymore anyway,
see below.

>  If destruction of a state machine involved no exit actions or
>  transitions, but merely released memory and other resources, and
>  similarly, if destruction of state objects involved no actions or
>  transitions, but merely released resources, then management of
>  those objects is simplified.  The library can impose upon such
>  objects that no transitions or actions are permitted.  This could
>  be handled by tracking a Boolean that indicates whether the FSM
>  was terminated and disallowing any further activity or by simply
>  saying, "I told you so," when things go wrong due to violating
>  that design tenet.

You've lost me here. Can you please rephrase what you mean with this?

>  If termination of a state machine was a specific action -- either
>  external by calling terminate() -- or internal via a state
>  transition, the resulting FSM seems to me to be more like one
>  would hand code.  Is that better?  I think so, but I'm no
>  expert.  I think that's what another poster was arguing.

I'm actually unsure about this too. It could well be that state_machine<> 
will lose the terminate() function.

>  If exit of a state was separate from destruction, it could throw
>  an exception.  At that point, the state machine could be declared
>  unstable and could be forcibly terminated.  (Remember that
>  Boolean I mentioned?)  IOW, you could require that all exceptions
>  be handled specifically via an exception handler installed by the
>  client to turn execeptions into transitions -- I think that's
>  essentially what you've described thus far.  Any unhandled
>  exception can be treated like C++ does it: it calls terminate().
>  (In this case, I mean terminate() for the FSM so that nothing
>  more may occur.)

terminate() is the wrong word for that. In FSM terminology it is clearly
defined what termination means.

>  With your approach, since construction implied
>  entering the initial state, that isn't necessarily possible.

No. There's state_machine<> ::initiate().

>  Sure, you may need to make changes to accommodate the ideas being
>  discussed, but let's focus on the ideas for now.  If the ideas
>  prove beneficial, even if you had good reasons to dismiss them
>  previously, then shouldn't we seriously consider them?

Darryl Green convinced me that exit() (or an equivalent feature that allows
the user to separate termination from destruction) is sometimes necessary.

>  Ideally, we need more FSM experts to participate in this
>  discussion in order to bring their experience to bear on the
>  discussion.  It seems rather one sided right now (the experienced
>  FSM person on the side of the current design, and the less
>  experienced on the side that's questioning some design
>  decisions).

I think Darryl and Eugene are quite experienced FSM folks...

Regards,

Andreas


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost