Hi: I recently joined Boost, and have been getting up to speed by following the various discussions. I realize that this, my first contribution, is a bit abstract, but I hope that it may provide some helpful perspective on the constructor/destructor vs entry/exit discussion. A common temptation in coding is to "take advantage" of some detail of the way some mechanism happens to work, while completely ignoring the intended meaning. The result is clever, frequently efficient, but obscure, difficult to understand (except for the original implementor) and inflexible. Occasionally their use with sufficient commenting is justified, but more often it is a mistake. (Back in prehistoric times, when I first joined the field, such tricks were called "hacks" and programmers with a propensity to use them were called, pejoratively, "hackers" -- but the meaning of that term has mutated three or four times since then). My first reaction (do note, before any hackles are raised, that I did say my *first* reaction) when reading this thread (without having read the material that it refers to) was that this appeared to be a classic example of this programming error. The argument certainly seemed to show all the ear-marks. 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. Questions as to the details of the way this worked, appeared to be defended as necessary: the tail wagging the horse, i.e., the implementation technique justifying the design rather than vice versa. A number of postings seem to indicate to me that others have had a similar reaction. On further thought, though, I have come to realize that this is not really justified. The design error appears to be (remember, this is based solely on the thread not the design itself) a much less serious one -- an error in identification of the abstractions. The problem, as I see it, is that what is being referred to as a finite state machine "state" is not that at all. A "state" is a rather static, declarative entity. Creating the "state" during execution and then associating entry and exit actions with its construction and destruction seems arbitrary and less than obvious -- especially when that starts to drive the design rather than being simply a mostly hidden detail of the implementation. In actuality, though, the objects being referred to as "states" are, in fact a kind of process-object corresponding to (the process of) *state activation*. What would more traditionally be thought of as a "state" of the finite state machine actually appears to correspond most closely to the class of the corresponding "state activation" object. With this in mind, identifying entry and exit of the state (beginning and ending of the state activation) with the constructor and destructor of the object is quite natural, and having entry/exit conform to the specific semantics/restriction of C++ constructors/destructors is then, quite reasonably, making the library C++ like in behavior. Furthermore, it clarifies (to me) the static/dynamic fsm library distinction. In a static library (like this one), the basically declarative "states" are represented declaratively as classes. In the absence of reflection mechanisms, the states are not actually represented at run time at all. On the other hand, in a dynamic library, the states are represented by some appropriate data structure and the state activation would most likely correspond to execution of appropriate methods specialized by delegation. This doesn't mean, of course, that this was the best design (I still haven't read the design, so I couldn't say), but it is certainly -- except for the terminological confusion -- a reasonable approach. Topher Cooper