[multi_index] scope_guard

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? Also, I read that you were disappointed with its performance, and I see that you only use it for checking invariants, when enabled. Do you plan on keeping it in Boost.MultiIndex? Have you considered submitting it for fast track review? Jonathan

"Jonathan Turkanis" wrote:
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?
Not needed in multi_index AFAIK. It also doesn't work well on VC6.
Have you considered submitting it for fast track review?
It may be considered to develop more powerful scope guard implementation, e.g. similar to: http://tnfox.sourceforge.net/TnFOX/html/group__rollbacks.html /Pavel

"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote in message news:cci3a4$nid$1@sea.gmane.org...
"Jonathan Turkanis" wrote:
I'm looking at your version of scope_guard in the current CVS.
intersted to know why you didn't include boostified versions of
I'm 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?
Not needed in multi_index AFAIK. It also doesn't work well on VC6.
Could you elaborate on the last point? I thought it might not work well on VC6 because of problems with __LINE__, but it seemed to work okay when I tried it.
Have you considered submitting it for fast track review?
It may be considered to develop more powerful scope guard implementation, e.g. similar to: http://tnfox.sourceforge.net/TnFOX/html/group__rollbacks.html
Thanks. I'll check it out. Jonathan

"Jonathan Turkanis" wrote
It also doesn't work well on VC6.
Could you elaborate on the last point? I thought it might not work well on VC6 because of problems with __LINE__, but it seemed to work okay when I tried it.
Doesn't work when Edit-and-Continue feature is enabled.
It may be considered to develop more powerful scope guard implementation, e.g. similar to: http://tnfox.sourceforge.net/TnFOX/html/group__rollbacks.html
Thanks. I'll check it out.
One may dream about ability to use lambda as scope guard expression... /Pavel

"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote in message news:ccj0lp$e9k$1@sea.gmane.org...
"Jonathan Turkanis" wrote
It also doesn't work well on VC6.
Could you elaborate on the last point? I thought it might not work well on VC6 because of problems with __LINE__, but it seemed to
work
okay when I tried it.
Doesn't work when Edit-and-Continue feature is enabled.
Thanks, I forgot that was the issue
It may be considered to develop more powerful scope guard implementation, e.g. similar to: http://tnfox.sourceforge.net/TnFOX/html/group__rollbacks.html
Thanks. I'll check it out.
One may dream about ability to use lambda as scope guard expression...
I'm going to post another message presenting a minimalist scope_guard which seems to work fine with lambda exprssions. I've never used Boost.Lambda before today, however, so I may be missing some important point. Jonathan

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

"Joaquín Mª López Muñoz" <joaquin@tid.es> wrote in message news:40ECEB73.6F7C82E0@tid.es...
Jonathan Turkanis ha escrito:
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.
Pavel reminded me about the problem with the __LINE__ macro on VC6 using (/ZI), and I'm not optimistic about finding a workaround. However, I don't regard lack of full VC6 support to be a show-stopper.
* The implementation should rely on Boost.PP so that a larger (and configurable) number of parameters can be handled.
I think this stuff can be delegated to Bind or Lambda. I'm going to post a message about this.
* 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.
I suggest two object generators: make_guard and safe_guard, the latter catching all exceptions. Jonathan
participants (3)
-
Joaquín Mª López Muñoz
-
Jonathan Turkanis
-
Pavel Vozenilek