Hi Mick Mick Hollins wrote:
I am currently using the history facility of boost::fsm. I've discovered that when I re-enter a state, X, via a history transition I don't actually re-enter the same instance of X that I was in before, but instead enter a newly constructed instance of X.
I just checked the UML spec regarding history transitions and it says that "Any necessary entry actions are performed", so given that boost::fsm uses constructors to represent entry actions I guess a new instance of X has to be constructed to ensure UML compliance.
Correct.
My actual concern is the effect this has on the "coolness" of state-local-storage (see http://boost-sandbox.sourceforge.net/libs/statechart/doc/faq.html#Whats_so_c...) It seems to me that state-local-storage, which I agree is generally cool, is particularly un-cool (and bug-inducing) in the presence of history transitions.
I'm not sure what a good alternative is, but just thought I'd raise the discussion.
When I implemented history, I had to make a choice between: a) The current behavior b) Abandon the entry-action --> ctor / exit-action --> dtor mappings and introduce enter() and exit() functions instead (exit() already exists for unrelated reasons). In non-history transitions the state objects would be constructed and destructed as they are now (and enter() / exit() would be called after construction / before destruction). However, when a "historized" state is exited, exit() is called but the state is not destructed. Instead, it is stored in the state_machine object. When a transition to history is made later the state is retrieved and only enter() is called. In my experience none of the above behaviors is entirely satisfying in practice because for some states you want a) and for others you'd want b). When a state contains two members you could even want a) for the first one and b) for the second one. Moreover, you can still get the desired behavior with a), by pushing the state-variables that you want preserved into outer states or the state machine object. As you observed, this essentially wrecks the benefits of state-local storage for those variables. I guess the main reasons that I settled with a) are: 1. It is simpler to explain and implement. 2. There were no votes in favor of b). In fact, you are the first user to bring this up. 3. History is used relatively rarely anyway. Then again, almost all my experience with state machines stems from the machine control field. Other areas might well have different requirements / expectations, so I'm interested in your use-case and how much of a difference b) would make. Also, there might be other, less intrusive approaches that I haven't thought about.
PS: does the history facility display the same semantics in boost::statechart?
Yes. Before switching to the current version I'd recommend reviewing the change history here: http://boost-sandbox.sourceforge.net/libs/statechart/doc/index.html Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.