Date: 2002-06-26 09:19:27
> -----Original Message-----
> From: Andrei Alexandrescu [mailto:andrewalex_at_[hidden]]
> <scleary_at_[hidden]> wrote in message
> > 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
> > why have ScopeGuard duplicate this functionality?
> I'd be interested in that, too.
The implementation from your article would have been simpler if it was based
on Function, but I don't think ScopeGuard needs to use Function directly;
see my reply to Joe.
> > . 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).
> This might become tricky if a ScopeGuard is created during
> stack unwinding.
Good point. But I think it could be covered well enough by a note in the
documentation, because this would be a very rare situation with well-written
. Unwind-only ScopeGuard objects would only be created if the block may
exit via exception.
. Destructors do not generally exit via exception.
. So, really the only time this might happen (in well-written code) is
when a function not originally intended to be called as part of stack
unwinding *is* called as part of stack unwinding.
This does bring up issues with the "context" of functions, though -- every
function that uses Unwind-only ScopeGuard objects should never be called
during stack unwinding.
> > . Have a type of ScopeGuard that follows strict scoping
> rules, but have
> > another type whose scope can be "transferred" to a calling function.
> This is what ScopeGuardImpl's copy constructor does.
ScopeGuard currently follows auto_ptr-like semantics; I was talking about
another type of ScopeGuard that would follow scoped_ptr-like semantics.
> > When you start looking at the different useful types of ScopeGuard
> > two things become apparent:
> > 1) It would be best as a policy-designed class
> It's not apparent to me. Part of ScopeGuard's beauty stems
> from its simple
> semantics, economy of means, and small interface.
Agreed. I retract my statement. :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk