Re: [boost] ScopeExit Review Begins Today

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
> ScopeExit.

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
> allow:
> - 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:
> 
> BOOST_SCOPE_EXIT_BEGIN(
>   (int, i)(BOOST_TYPEOF(x + y), j)(bool&, commit))
> {
> }
> BOOST_SCOPE_EXIT_END
> 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
platforms/compilers.

> - 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.

--
Alexander