David Abrahams wrote:
>  "Andreas Huber" <ah2003@[...].net> writes:
> 
> >> I'm also concerned that the current fsm destruction/exit action
> >> implementation model results in an environment where I should avoid
> >> using exit actions that have any significant external effects
> >> because
> >> I don't want/expect them to be run when/if the fsm is destructed.
> >
> > Concern noted. This is actually the central disagreement between me
> > and Dave Abrahams. If you have any real-world examples, I'd be
> > *very* interested to see them.

>  Here's one I'm pulling out of the air, since I don't have any
>  real-world experience *with FSM exit actions*.  I hope my extensive
>  real-world experience with programs in general, state and invariant
>  management, and error handling counts for something.

It certainly does.

>  A state X has a local buffer of data to be written to disk upon making
>  a successful transition from X.  The presence of that data on disk
>  indicates something important about what's happened in the state
>  machine, and you *don't* want the data on disk unless you have made
>  the transition from X successfully.

Since most of my experience with FSMs comes from working with code
generators that do not offer the state local storage feature, I would have
written that buffer to the disk in a transition action, which is associated
with all transitions leaving that state. With boost::fsm this means to move
the buffer to transition context, which admittedly could sometimes look a
bit arificial. Darryl Green had a much better idea: He would use a custom
reaction to write the buffer to the disk and would afterwards initiate the
transition (the whole sequence is therefore an in-state reaction immediately
followed by a transition). This way the buffer does not have to be moved out
of the state.

Yes, this solution has the slight problem that one has to do this for all
transitions originating at the state X. Although it can be done without
duplicating any of the actual action code, one still has to explictly
mention this for each transition in the reaction list of the state. However,
and this is the main point here, well-designed real-world composite state
machines tend to have very few transitions originating at each state. You
often have one, less often two, rarely three and almost never four
transitions originating at one particular state. Even if you have more than
one reaction, IME it is unlikely that you want to save the buffer when any
of them is triggered.

My experience with FSMs mainly comes from controlling machinery and I have
found the design patterns outlined above to be valid there. While I expect
that they are also valid elsewhere, I cannot be entirely sure and that's
also one of the reasons why I insisted on an example.

>  It would be a bad idea to write that data out if the FSM's controlling
>  process decided to simply discard the FSM when it was in state X.
>  Also, putting the instructions to write the data in a state destructor
>  could require the otherwise-unneccessary quashing of exceptions from
>  the function used to write the data to disk.

With the solution mentioned above this is no problem at all.

>  I said long ago that I was going to stop poking at this one, and
>  didn't, because I had the sense that issues in this area, and the way
>  you were reacting to my poking, might indicate that there were other
>  problems.

I can only guess what exactly you mean with this, but it does sound like an
accusation of me somehow evading your questions, see below.

>  I don't feel as though much progress has been made, and you
>  seem to feel that trying to convince me of anything by example is
>  futile.

I did provide one example many posts ago (the pump in the dishwasher). Also,
let me quote what you had to say about this in another post:

David Abrahams wrote:
> > I think a foundation for a decision is not flimsy when the behavior
> > in question has proved to be useful in practice. So far nobody, who
> > seems to have experience with non-trivial FSMs, has doubted that it
> > is useful to terminate a state machine when it is destructed (my
> > assumption A1).
> 
>  I don't doubt that it's often useful.  I also think it is surely
>  sometimes highly undesirable.  If you remove A1, the "useful" behavior
>  is trivial to achieve without transforming the FSM, so it seems that a
>  design without A1 is both more flexible and more orthogonal.

Since you don't doubt that it's often useful, why exactly should I then
provide further examples in support for it? They will surely not convince
that your "sometimes highly undesirable" assertion is invalid (that would
seem highly illogical). BTW, I don't think that it is completely invalid
either. What this all really boils down to is an interface that is easy to
use and works well for the vast majority of the use-cases and requires
workarounds for a minority of the use cases. I insisted on an example also
to show how simple those workarounds can be and I doubt that they can
typically even be called workarounds as they don't make machine design worse
in any way (especially not with Darryl's trick).

>  So really, now I'm going to stop worrying this issue.  May
>  other peoples' posts be more helpful than mine have been!

Having slept over this and having spent pretty much the whole morning
rereading our posts and reflecting on this whole discussion, I'm a bit at a
loss what exactly went wrong. While I tried to always give accurate and
to-the-point answers, you seem to have misunderstood them too often, what
culminated in your accusation of me reasoning circularily. I don't want to
imply that the problem necessarily lies on your side. In the beginning I
definitely made the mistake that I assumed too often on what we would agree
and what not. However, this alone couldn't possibly have led to the
situation we now have. I don't have much of a clue what else I have done
wrong.

If other Boosters reading this have more of a clue then I would highly
appreciate it if they'd let me know by private email.

Regards,

Andreas


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