Boost logo

Boost :

From: scleary_at_[hidden]
Date: 2002-06-26 09:19:27

> -----Original Message-----
> From: Andrei Alexandrescu [mailto:andrewalex_at_[hidden]]
> <scleary_at_[hidden]> wrote in message
> news:22602E7E3B92D411969B0090273CC28B1D21EC_at_cecexchange.jervis
> > 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.

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
> 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.

Agreed. I retract my statement. :)


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