"Andreas Huber" <ah2003@gmx.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. I'm certain I could come up with five more of these given an hour, but if you demand an example that I know exists in some real FSM code, I can't help you. 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. 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. 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 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. So really, now I'm going to stop worrying this issue. May other peoples' posts be more helpful than mine have been! -- Dave Abrahams Boost Consulting http://www.boost-consulting.com