Date: 2002-06-21 12:48:17
I've messed around in the past with different versions of classes that would
run arbitrary code when destroyed. Here's some different functionality that
I've found useful:
. Allow *any* action to be run; Boost.Functional can already support this;
why have ScopeGuard duplicate this functionality?
. Have a type of ScopeGuard that wraps its action in try...catch, similar
to the article, but have another type that does not.
. Have a type of ScopeGuard that only runs its action if the destructor
was called as part of stack unwinding, not normal block scope exit (useful
for "rollback" operations).
. Have a type of ScopeGuard that follows strict scoping rules, but have
another type whose scope can be "transferred" to a calling function.
When you start looking at the different useful types of ScopeGuard classes,
two things become apparent:
1) It would be best as a policy-designed class
2) It's very close to a SmartPtr. So close, in fact, that I make the
claim that a ScopeGuard *is* a SmartPtr.
Food for thought. :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk