From: Alexander Nasonov (alnsn_at_[hidden])
Date: 2007-08-22 03:57:38
Andrey, thanks for the review.
> - The usage of Boost.Typeof may be discouraging because of need to
> register user-defined types. This might be no problem for types that
> indeed are defined by the user, but there are cases when they are not
> (OS API, third party libraries, etc.). And interaction with such APIs
> in a transaction-like manner is a quite probable place to employ
The library is oriented towards C++0x with decltype proposal accepted ;-)
I realise typeof emulation mode is discouraging and I tried to come up
with a good syntax for explicit types as you suggest below.
> - The scope-exit block arguments are taken by reference. I consider
> this as a drawback because it is most often desirable to fix the
> environment state at the point where the guard is created. The most
> frequent and, in majority, the only exception to this is the
> "commit/dispose" flag. Playing otherwise may lead to subtle errors.
> Consider the following examples:
> These are just illustrations, I understand that I could have created
> copies of the needed variables on the stack. But I think this should
> be the default behavior of the library, and passing by reference
> should be an available option.
These are good examples. Would you accept the syntax suggested in my other
reply to you message if it's ever possible in C++
BOOST_SCOPE_EXIT( byref(r) byval(v) ) ?
or, if some C++ contruct X exists such that 'X id' and 'X &id'
are both valid C++ and both can be transformed to typeof(id),
then I could write the ScopeExit macro like this
BOOST_SCOPE_EXIT( (&r)(v) ) .
> That said, I'd like to vote to add a new set of macros that would
> - Explicitly state the scope-exit argument types
> - Explicitly state if arguments should be bound by reference or not
> These macros should not depend on Boost.Typeof in any way (not even
> #include it). The syntax might involve PP tuples like this:
> (int, i)(BOOST_TYPEOF(x + y), j)(bool&, commit))
> Variables i and j are bound by value and commit - by reference in the
> snippet above.
Comma between int and i is unnatural but it's not possible to extract i
out of '(int i)' or '(int& i)'.
> - Configuration page. It says that BOOST_SCOPE_EXIT_FASTER_IMPL is not
> supported which makes me feel like I'm discouraged from using it. May
> be it shouldn't be documented then?
It probably shouldn't. My intension was to advertise this trick
so that someone smarter than me could supply a patch for other
> - If BOOST_SCOPE_EXIT_FASTER_IMPL optimizes something, it would be
> nice to see performance comparisons to the non-optimized version.
> - Anyway, performance section would be appreciated. I'd like to see
> the speed impact comparing to other alternatives you listed in the
> docs. In particular, I'd like to see the difference depending on the
> scope-exit block arguments number. I can see some performance notes on
> the Implementation page, but there are no experimental data.
I don't want to mislead people. There are so many processors, compilers
and compilation flags that I suspect my performance comparison may
give opposite results on different computers.
I don't think performance depends on number of arguments unless you pass
50-100. It's like measuring performance of function calls with a different
number of arguments.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk