on Fri Oct 05 2012, Gennadiy Rozenal <rogeeff-AT-gmail.com> wrote:
Dave Abrahams <dave <at> boostpro.com> writes:
I haven't looked at the code, but I wonder if Gennadiy could improve the situation by putting the debug break in the dtor of a return value, so you gather up all this information in the nested function calls, and then only drop into the debugger where the test macro is invoked?
I do not follow what you are saying. What return value you refer to? And what kind of debug break?
Macro resolves to something like:
check_function( expression under test, some context,... )
Since function arguments are evaluated in unknown order, it it possible the context collection expressions executed first.
IIUC the claim is that the call stack at the point of the breakpoint looks like: user_function1 user_function2 boost.test_function1 boost.test_function2 boost.test_function3 boost.test_function4 break I obviously don't understand the problem completely, but my suggestion was, instead of breaking in boost.test_function4, to return something from boost.test_function1 whose dtor contains a debug break. If valuable information is being collected in boost.test_functionX, store it on the heap if necessary so it can be available at the point of the debug break. Hope this is useful, but it might not be. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost