Re: [boost] ScopeExit Review Begins Today

From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-08-22 13:23:05

Hello Alexander,

>> - The usage of Boost.Typeof may be discouraging because of need to
>> register user-defined types.

> The library is oriented towards C++0x with decltype proposal accepted ;-)

That's nice, but I'd like to make use of the library on legacy
compilers too.

>> - The scope-exit block arguments are taken by reference.

> 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) ) ?

This would be a very nice addition for the typeof-based macros. But, I
still would like to have an alternative syntax not involving
Boost.Typeof, as it's quoted below.

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

I think, the above version with byref and byval is more natural, so I
like it more.

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

I can live with that. We already have unnatural PP.Seq here, so this
extra comma doesn't make it any worse.

>> - Anyway, performance section would be appreciated.

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

Hmm, to my mind it is the absence of information that misleads people.

We have a macro here and a new user will not have a clue what will it
become after preprocessing. We should not put the user into
implementation details just to let him estimate performance costs.
Even after doing that he won't know for sure if his home-grown scope
guard with lambda functors will be better or worse than the lib.

I think, a short table with test results on most common compilers
(say, GCC and VC 7.1) would be a good performance indication to users.

-- 
Best regards,
 Andrey                            mailto:andysem_at_[hidden]