Jonathan Turkanis ha escrito:
Hi Joaquín,
I'm looking at your version of scope_guard in the current CVS. I'm intersted to know why you didn't include boostified versions of the macros ON_BLOCK_EXIT from Andrei and Petru's original article. Was it just because you didn't need it or because you found it objectionable for some reason?
I just didn't need that generic macro. Scope guards are used in the library through macros like BOOST_MULTI_INDEX_CHECK_INVARIANT, whose names are more indicative that a generic ON_BLOCK_EXIT. I don't think ON_BLOCK_EXIT will have any problem in general: the aforementioned macros are syntactically identical. (One exception: CW 8.3 has a bug with one compiler setting that makes guards work incorrectly. This can be fixed with a pragma, check for instance line 69 of multi_index_container.hpp.)
Also, I read that you were disappointed with its performance, and I see that you only use it for checking invariants, when enabled.
Yep, that's correct. Rough measurements showed a 5% degradation wrt a classic try/catch approach. YMMV.
Do you plan on keeping it in Boost.MultiIndex?
Yes. It is used in debug facilities, where efficiency is not a crucial concern.
Have you considered submitting it for fast track review?
Why not, if people are interested (note, however, that past attempts at submitting a scope guard library have failed.) At least the following would have to be addressed in order to improve the implementation for submission as a public library: * Provide (an equivalent of) ON_BLOCK_EXIT. * The implementation should rely on Boost.PP so that a larger (and configurable) number of parameters can be handled. * At the point of destruction of a sope guard, currently it is assumed that the user provided function does not throw. This is a debated issue, maybe what to do about exceptions here can be handled by a policy. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo