RE: [boost] Re: [prereview request][fsm]
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.
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
Andreas Huber <ah2003@gmx.net> writes:
GC'd language, for the most part, you wouldn't devote any exit ^^^^^^^^^^^^^^^^^ action code to resource releases.
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
That's why I wrote "for the most part". You misinterpreted me and the whole thing about GC turned into a big distraction. Exit actions are no different from entry actions and transition actions from an abstract POV in an FSM. They have equal status, and there's no reason at all to restrict whether one of them can throw exceptions, not least the one that executes *first*. IMO your error handling model is too complicated to reason about easily, that complexity is making it hard for you to see its flaws. But complexity of an error-handling model is a flaw in itself. Error handling is hard enough to get right in principle with a simple model. Simplify, simplify, simplify. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
IMO your error handling model is too complicated to reason about easily, that complexity is making it hard for you to see its flaws. But complexity of an error-handling model is a flaw in itself. Error handling is hard enough to get right in principle with a simple model. Simplify, simplify, simplify.
I sort of agree. I have also come to the conclusion that it is complex, maybe even too complex. Problem is, I don't currently see any way how to simplify it *without* removing much of the functionality :-(. Regards, Andreas
"Andreas Huber" <ah2003@gmx.net> writes:
David Abrahams wrote:
IMO your error handling model is too complicated to reason about easily, that complexity is making it hard for you to see its flaws. But complexity of an error-handling model is a flaw in itself. Error handling is hard enough to get right in principle with a simple model. Simplify, simplify, simplify.
I sort of agree. I have also come to the conclusion that it is complex, maybe even too complex. Problem is, I don't currently see any way how to simplify it *without* removing much of the functionality :-(.
I think if you'd consider dropping A1 you'd discover that it's possible. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (3)
-
Andreas Huber -
Brian Braatz -
David Abrahams