Re: [boost] ScopeExit review

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