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@mail.ru