Re: [boost] ScopeExit Review Announcement

From: Kim Barrett (kab_at_[hidden])
Date: 2007-08-08 21:32:51

I'm submitting an early review of the proposed Boost.ScopeExit
library, since I won't be able to do anything with it during the
proposed review period.

First, I really like this proposal, and think it should be accepted
into Boost. I've been interested in it since I first saw it discussed
on the developers list, and proposed having our group adopt its use as
soon as we updated to a version of Boost that supported it, even if
this proposed library was itself not yet included. I've read the current
documentation and think it is quite good.

I imagine some people might think that having the transaction cleanup
actions next to the start of the transaction clutters the main line of
execution code with "exception handling" code. However, as a long-time
user of various programming languages with "finally" style cleanup
actions after a protected body (various Lisp dialects, Java, Python),
I've often found that having the cleanup action far removed from what
is to be cleaned up makes it difficult to ensure during maintenance
that the cleanup actions are always being updated appropriately. A
common solution to that problem is to break the protected body out
into a helper function to reduce that lexical separation. But, that's
no less intrusive than registering the cleanup actions before the
body. I've written some code snippets in the style of this library
just to get an idea of the look, and I like the result.

I've seen a lot of blatantly exception unsafe code in the couple of
years I've been using C++, and my impression is that at least some of
the reason for it is the syntactic inconvenience of doing things
right.  This library provides a superb wrapper around that
inconvenient syntax. It would be better if the values needed by the
cleanup body could just be referenced lexically, without the need for
the scope-exit-args-pp-seq, but that's a language change (or perhaps
some extremely non-portable implementation code), not a library.

My only (mild) quibble is the decision to use a PP sequence for the
arguments. I might prefer that this library be forward looking and
assume variadic macros, with backward compatibility variants that use
the PP sequence technique for use by those who need to support
compilers that don't support variadic macros.

I haven't actually used this library yet; I'm in the process of
upgrading my group's project from boost 1.33.1 to boost 1.34.1 even as
I type this, and probably won't have a chance to use it before the
vacation that is the reason for this early review. Once I get back
I'll be trying it out on some more recent versions of gcc than those
noted in the documentation as having been tested.