[Boost-announce] [review] BOOST_SCOPE_EXIT review results

From: John Phillips (phillips_at_[hidden])
Date: 2008-05-07 15:22:58

  Here are the review results for the Scope Exit library, submitted by
Alexander Nasonov.

  I would be remiss if I didn't begin these results with an apology and a
thank you. The review wizards are sincerely sorry that the result of this
review took so long to be presented, and very grateful that Alexander has
been so patient and according to a post on the forum has even been working
to improve the library in the interim when time allowed.

  The following people contributed to the review.

Kim Barrett, Steven Wantanabe, Oleg Abrosimov, Andrey Semashev, Peder Holt,
Johan Nilsson, Maxim Yanchenko, Pavel Vozenilek, Aaron LaFramboise, Ben
Kuppers, Goran Mitrovic, Tom Brinkman, Martin Wille, Joseph Gauterin, Matt
Gruenke, Dave Abrahams, Christian Holmquist, Mathais Gaunard, Michael
Marcin, Daniel Wallin, Zach Laine, Sid Sacek, Wang Yun, and Ilya Sokolov

  After carefully considering the review comments, I'm pleased to announce
that the Scope Exit library is accepted into Boost.

  As is almost always the case, there are some notes for improvement for
this library, and in this case there is even a suggestion for a substantial
future restructuring.

  Let's start with the big one first. As it is currently implemented,
SCOPE_EXIT suggests a method for creating a general closure mechanism as a
library. This is a useful enough idea that many of the reviewers strongly
encouraged Alexander to do it, and provided ideas for implementation
details. Alexander should continue to work on this, and when it is ready for
review, submit it to Boost. When he gets it accepted into boost, he should
consider reworking SCOPE_EXIT to build it on top of the closures and a more
traditional scope guard. If this is practical, he should create the new
implementation and possibly submit it for a mini-review, since it will be
such a big change from the current form.

  On to the other issues.

  There were a number of comments on the documentation. Some of the most
detailed were in the review by Pavel. Much of the requested information is
currently present in the documentation, but not in a format that new readers
find intuitive. Along with reorganization, some more examples, some more
comparison information, and some actual performance information would be a
good idea.

  Kim would like to see variadic macros supported in the implementation.
This is a good idea if a large fraction of currently available compilers
support them, but otherwise a low priority.

  Currently the library requires the user to include type_of headers, even
though there is no place in the user code where a type_of appears. This will
be confusing for many new users. If possible, look for a way to make the
library more self-contained in this regard.

  Other reviewers requested ways to use the library without any type_of
dependence. This would expand the audience for the library, but may not be
practical. Consider it and act appropriately.

  Aaron requested some syntactic sugar for things like if(condition) tests.
This may not be a good choice, since it greatly expands the interface while
providing only minor simplifications to calls. Consider it and choose.

  The code needs to check for msvc compilers, since the __LINE__ statement
has to be replaced for them.

  BOOST_SCOPE_EXIT_FASTER_IMPL should be removed. It isn't always faster,
and putting experimental features in a release makes no one confident. If it
becomes stable, cross-platform and consistently faster, then it can come
back.

  BOOST_SCOPE_EXIT_TRY and BOOST_SCOPE_EXIT_CATCH_ALL are not very useful

  There is a compile warning because boost_scope_exit_params_struct_nn does
not have an assignment operator. Define one and it will go away.

  Look for ways to make the syntax clearer. Goran pointed out that he doubts
code reviews at his job or many others would allow the current syntax. So
far, the best suggestion seems to be BOOST_SCOPE_EXIT((cref c) (ref r) (val
v)). This also addresses desires to be able to pass by other than
references.

  There was a request for the ability to nest scope_exits and build more
complicated structures. I don't see how this could be done in an exception
safe manner, so it is probably not a good idea.

   There was an extended discussion on the use of macros in the public
interfaces of Boost libraries. It is certainly true that indiscriminate use
of macros is a bad idea, but there is no indication that that is the case
for this library. As is always the case for any Boost library, the real
question should be "What is the best way to provide the best
functionallity?" In this case, no suggestions other than macros have come
forth, so macros are the best available choice.

  My thanks again to everyone who participated, to Alexander for creating
and submitting the library and for his patience,  and to Jody for organizing
the review period.

            John Phillips
            Review Wizard

-- Those only are happy, who have their minds fixed on some object other
than their own happiness; on the happiness of others, on the improvement of
mankind, even on some art or pursuit, followed not as a means, but as itself
an ideal end. Aiming thus at something else, they find happiness by the way.

John Stuart Mill