Allow variables to be marked for output in test failures

[jonstewart]

e.g., something like this:

for (int i = 0; i < n; ++i) {
SCOPE_MARK(i);
SCOPE_ASSERT(SomethingAbout(Vector[i]));
}

Failure: line XX, SomethingAbout(Vector[i]), i = 4

Other proposals for syntax?

[uckelman]

It would be better if the marking happened automagically, but maybe that's not doable.

[jonstewart]

I don't know of a good way to get a reference to the variables automagically. Also, for safety's sake, I might have to make a copy of the variables, which means that what gets reported will be the state at the time of the copy, not necessarily at the time of the exception being thrown. But that should allow the careful programmer to do what s/he wants, still.

[jonstewart]

Maybe just use a variadic macro instead, and then take on all the things you want printed as additional arguments to the assertion?

SCOPE_ASSERT(SomethingAbout(Vector[i]), i);

[jonstewart]

Yeah, I think the thing to do is:

1. Make the asserts into variadic macros, that accept any number of arguments being tacked on beyond what are required.
2. The macro #'s __VA_ARGS__ to get a string of the expressions.
3. The macro then invokes some kind of variadic template function for printing, so that the expressions are bundled up in a type-safe fashion along with the string containing what they were.
4. That function can tokenize the string of expressions into individual ones, to make printing nice as key=value pairs, e.g., foo=1, bar="five", baz=3.1415926.

Either the expression values need to be copied OR the stringification needs to be completed before the exception is thrown, to be sure that we don't need to refer to values which have been cleaned up by unwinding.

Unfortunately, there's no good way with variadic macros to uncons __VA_ARGS__. So either we have to figure out a way for our tokenization of the stringified __VA_ARGS__ to be correct in the face of all possible expressions (...), or accept that it won't be correct and make it work for common cases and document them, or print things out as two corresponding tuples instead of key=value pairs, e.g., (foo, bar, baz) => (1, "five", 3.1415926). This last option is easily doable, but not as easy to read as key=value.