From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-06-25 16:22:24
<scleary_at_[hidden]> wrote in message
news:22602E7E3B92D411969B0090273CC28B1D21EC_at_cecexchange.jerviswebb.com...
> 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?
I'd be interested in that, too.
> . Have a type of ScopeGuard that wraps its action in try...catch,
similar
> to the article, but have another type that does not.
I think the best approach is to have ScopeGuard not use try/catch in its
destructor, and create a simple wrapper template eat_exceptions that can be
composed with the user-passed function.
> . 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.
> . 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.
> 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
It's not apparent to me. Part of ScopeGuard's beauty stems from its simple
semantics, economy of means, and small interface.
> 2) It's very close to a SmartPtr. So close, in fact, that I make the
> claim that a ScopeGuard *is* a SmartPtr.
For one thing, ScopeGuard uses the "const reference initializer" idiom which
leads to efficient code but which is not used with smart pointers.
Andrei