|
Boost : |
From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2004-07-08 01:36:35
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk