ScopeExit Review Announcement

Alexander Nasonov's ScopeExit submission will be formally reviewed August 13 - August 22. The current submission has been uploaded to http://boost-consulting.com/vault/index.php?action=downloadfile&filename=scope_exit-0.04.tar.gz&directory=& It's also available at http://tinyurl.com/2z6qg2 Online documentation is here http://194.6.223.221/~nasonov/scope_exit-0.04/libs/scope_exit/doc/html/index...

Sorry for the potentially stupid question. But what's the difference between this library and the guard lib I found in the sandbox. I like the guard lib a lot and use it for month, already. Regards, Christian

Christian Henning writes:
Sorry for the potentially stupid question. But what's the difference between this library and the guard lib I found in the sandbox. I like the guard lib a lot and use it for month, already.
Read the Alternatives section http://194.6.223.221/~nasonov/scope_exit-0.04/libs/scope_exit/doc/html/scope... -- Alexander

Jody Hagins wrote:
Online documentation is here http://194.6.223.221/~nasonov/scope_exit-0.04/libs/scope_exit/doc/html/index...
Seems to be missing the CSS? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Joel de Guzman <joel <at> boost-consulting.com> writes:
Seems to be missing the CSS?
I'm not absolutely happy with a style of this documentation but I think it's good enough for review. Later I'm going to generate the whole boost documentation and see if my library has same look&feel as the rest of boost. If you tell how to copy .css file(s), I'll do this tomorrow or next week. -- Alexander Nasonov

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.

Kim Barrett <kab <at> irobot.com> writes:
First, I really like this proposal, and think it should be accepted into Boost.
Thanks!
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.
I totally agree with you.
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.
How would you implement dispatching if there is only one argument? E.g. BOOST_SCOPE_EXIT(i) vs. BOOST_SCOPE_EXIT( (i) ). AFAIK, there is no equivalent to mpl::is_sequence in PP. -- Alexander

At 4:24 PM +0000 8/9/07, Alexander Nasonov wrote:
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.
How would you implement dispatching if there is only one argument? E.g. BOOST_SCOPE_EXIT(i) vs. BOOST_SCOPE_EXIT( (i) ). AFAIK, there is no equivalent to mpl::is_sequence in PP.
I wouldn't. When I said "backward compatibility variants" I meant macros with different names, with the "good" names used by the variadic versions. So something like BOOST_SCOPE_EXIT_PPSEQ (with no preference intended for that specific naming convention).

Kim Barrett <kab <at> irobot.com> writes:
I wouldn't. When I said "backward compatibility variants" I meant macros with different names, with the "good" names used by the variadic versions.
OK, I didn't realize that.
So something like BOOST_SCOPE_EXIT_PPSEQ (with no preference intended for that specific naming convention).
Not sure that people will like it. The macro is already long so adding a suffix to it would make it harder to type and read. Don't forget the library also supports BOOST_SCOPE_EXIT_TRY, BOOST_SCOPE_EXIT_TPL and even BOOST_SCOPE_EXIT_TRY_TPL. Have a nice vacation! -- Alexander
participants (5)
-
Alexander Nasonov
-
Christian Henning
-
Jody Hagins
-
Joel de Guzman
-
Kim Barrett