David Abrahams wrote:
I'm reading it like a bible only when it helps to argue my case ;-).
I know there's a smiley, but you're not doing your credibility any favors with that statement. It makes me wonder how many other decisions in the design have such a flimsy foundation.
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). BTW, as pointed out by someone else the user *does* have a choice. If she happens to have an exit action that she'd rather not have executed upon destruction then she can always transform the machine part in question such that her action is executed as part of a transition action instead (I would consider it a design error not to do so). Every Moore machine (an FSM that has only entry and exit actions) can be transformed to a Mealy machine (an FSM that has only transition actions) and vice versa.
If you want to convince _me_ (I'm not saying that's important or anything), you're going to have to make the case for why an FSM object should make transitions (or state changes, if you like) when it is destroyed. To me it seems like there are very obvious use cases supporting the argument that it should *not* happen.
As pointed out above, you *can* implement your FSM in a way such that no action is ever executed upon destruction. Whether such a machine is typically well-designed is an altogether different question (I'm not saying that such a machine is always badly designed). State machines do have a theoretical/mathematical background. Despite this background, I need to make some assumptions when I model them in C++. I strongly believe that not making such assumptions would have lead to an interface that is more complex than necessary for most real-world applications. For one in X applications an assumption could well turn out to be wrong and the application needs to resort to work-arounds as a result (as outlined above). To me, said assumption is justified if X turns out to be sufficiently high. The assumptions are based on practical experience, which is of course not provable. Since you seem to accept only strictly provable arguments, I will never be able to convince you.
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?). Regards, Andreas