From: Maxim Yanchenko (maximyanchenko_at_[hidden])
Date: 2007-08-22 13:54:59
I vote to accept the library into Boost.
* What is your evaluation of the design?
* What is your evaluation of the implementation?
The design and implementation is clear and straightforward.
Of course we'd like to have such a library with better syntax, but current C++
doesn't allow to make it better.
* What is your evaluation of the documentation?
Clear and understandable.
* What is your evaluation of the potential usefulness of the library?
I believe the library is very useful, I will use it in my work.
It helps to avoid writing complex rollback code clean and in-place.
Another nice feature comparing to using lambdas is the ability to place
breakpoints inside the rollback code.
Without ScopeExit you can only achieve this by using manually-written scope
guard class from scratch
* Did you try to use the library? With what compiler? Did you have
any problems?
Yes, played with the examples from documentation, GCC 3.4, no problems noted.
* How much effort did you put into your evaluation? A glance? A
quick reading? In-depth study?
Compiled, played with examples, looked into the implementation.
* Are you knowledgeable about the problem domain?
I'm sure everyone is :)
* Do you think the library should be accepted as a Boost library?
Yes.
A couple of general comments after reading other reviews.
1. The fact that the library takes all arguments by reference looks unavoidable.
If it allowed passing by value (i.e. making copies) - the copy constructors can
throw, and this exception will be thrown after you made the change to your
container/whatever you'd like to rollback, and before you setup the rollback
action. So you can't guarantee that your rollback action will be executed.
So, in case you need a copy - it's much safer to create this copy before making
the change to your container/whatever. It will also express your intention more
clearly.
2. Of course it would be great to have a full-featured scope guard library in
Boost, but its absense is not an excuse to reject ScopeExit, otherwise we need
to reject scoped_ptr/scoped_array etc, as they are forms of scope guard. In
general, I believe we can't reject a library A just because Boost misses a
library B.
Thanks,
Maxim