From: Andrey Semashev (andysem_at_[hidden])
Date: 2005-09-20 15:55:03
The new version is available in the Sandbox (I moved it into Function
Here is a shord summary about changes:
- Various cosmetic changes, including macro and function names.
- Exception support code (with_catcher policy) moved into a separate file.
- Added a helper function "catching" to simplify use of with_catcher policy.
- Unique names generating code moved into a separate file. By the way, maybe
this code should better be in Boost.Preprocessor? See
- Revised the guard_ptr class, moved it up to boost namespace. It is now
resided in guard_ptr.hpp.
- The actions_trace class was considered to be too specific and was
eliminated. The new guard_adapter class is supposed to expand the
functionality of holding scope guards in containers to every STL-compatible
container (sequental or associative) and even to the standard container
wrappers such as stack, queue or priority_queue. See guard_adapter.hpp for
- I hope I've fixed problems with VC6 (and even maybe BCB) I've been
reported, but I can't tell for sure since I can't try it. At least the code
that uses scope_guard.hpp should work (once again, I hope). Maybe I'll have
a chance to test it on VC6 in a week or two, but now I'm walking blindly.
As always, I've tried it on VC7.1, ICL9 and MinGW (GCC 3.4.4).
Few words about what I'm concerned about:
- The naming of arm/disarm methods of scope guard. They are used to change
the activity status of the guard. Personally, I feel fine with them but the
commonly used name for disabling the guard is "dismiss" and I just can't
figure out its suitable counterpart in English. I wonder if anyone have a
proposal about this.
- The naming of the function make_guarded_call (in previous version it was
make_transaction) is what I'm not sure of. This function in addition to a
scope_guard creation calls some another functor. The semantic is grouping
the "do" and "undo" actions in the user code. Does anyone have a better
- I have received a proposal of ability to allocate space for several
scope_guards on the stack. In current implementation when using
guard_adapter and guard_ptr with some container the guard objects will be
allocated in the heap which might be slightly slower than if it would be on
the stack. So the most probable implementation of such proposal shall be a
separate static container. Does anyone have any thoughts about this? How
much would you need such functionality?
I think, I've reached some point release (unless anyone have proposal about
namings). At least, the main scope guard implementation seems to be stable.
So I would like to check in this version to CVS (or, maybe, if someone do
this for me) if there are no arguments against this. Once I have done this I
could start making BoostBook docs (now there are only doxygen-like comments
in the code) and make some unit tests.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk