Boost logo

Boost :

From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-28 05:00:48

Brian Braatz <brianb <at>> 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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at