RE: [boost] Re: ScopeGuard

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

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
code:
  . 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. :)

        -Steve
http://my.voyager.net/~shammah/