Boost logo

Boost :

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-06-25 16:22:24

<scleary_at_[hidden]> wrote in message
> I've messed around in the past with different versions of classes that
> run arbitrary code when destroyed. Here's some different functionality
> 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.

> . Have a type of ScopeGuard that wraps its action in try...catch,
> 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
> 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.


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