Brian Braatz <brianb <at> rmtg.com> writes:
My 2 cents """""""""""""""""" This is certainly doable. However, I'm unsure whether the current
design allows a you-don't-pay-for-what-you-don't-use implementation of
such a feature. Plus, I'm still not convinced that this feature would be used more than rarely. Do you have some real-world use cases in mind?
[David Abrahams] Unfortunately I'm not so familiar with what exit actions in FSMs are typically used for, but from an abstract point of view I don't think of resource releasing as an "action". If you were writing this stuff in a GC'd language, for the most part, you wouldn't devote any exit action code to resource releases. """""""""""""""""' I think this is a very good point as MS seems (IMO\whether I like it or not) to be driving us down a managed GC path for future C++ efforts. This is something to deeply consider. Not that MS is "everything", but they do have a lot of C++ developers using their tools and os's.
Please read my followup to Daves post. There I explain why you would need exit actions to release resources even if we had GC. The problem with GC is that it is not deterministic. Deterministic cleanup must be the default, because in state A you very often use non-shareable resources that are also used in state B. Relying on GC for this will lead to incorrect behavior. All the GCed languages I know solve the problem of deterministic cleanup with a separate Dispose() function. All classes that potentially need to deterministically clean up after themselves offer such a Dispose() function (in .NET there is even an interface for that). If I was to develop an FSM framework in a GCed language then users would need to implement Dispose() to add an exit action to a state. Regards, Andreas