[boost] Re: ScopeGuard

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