jasonmolenda added a comment.
A couple of thoughts / two cents.
I don't mind the current if (log) { ... } style of logging, even with the
PRIx64's and having to do filepath.GetPath().c_str() and all that. I like
being able to do extra work in a if (log) block of code -- create a
SymbolContext for something or whatever, and as I'm debugging that section of
code I like to be able to put a breakpoint there and look more closely. If
this is all in a preprocessor macro, a breakpoint is going to stop me on the
if() and then I'm trying to step through a macro? And if my computation is
down in a lambda I need to figure out how to put a breakpoint in that or step
into that somehow to look at the values being computed. How do I create a
SymbolContext my_symctx(...); and then include that in what I log if I have to
do all of this in the formatv arguments?
I'm not thrilled with the formatv reinvention of format specification. The
printf formatters are a bizarre little invention, but it's a bizarre invention
that we've all worked with for decades and everyone who works in C knows well.
The formatv format specification may be superior, but I don't want to see
innovation here, I want clarity with the linga franca that every C programmer
knows. I think the barrier to adopting something non-standard is very high.
The formatv format specification string seems to explicitly mention the
ordering of the arguments, like llvm::formatv("{0} {1} {2}", first, second,
third). I'm guessing this allows you to print the arguments in different order
than they appear? Like llvm::formatv("{0} {2} {2} {1}", first, second,
third)? What's the benefit of this vrs. the uncertainty of which arguments are
used in different parts of the string (short of counting them out by hand)? If
I have a formatv format specification like "{0} {1} {2} {3} {4}" and I want to
insert an argument between 2 and 3, I need to renumber 3 and 4 now? Or do I do
"{0} {1} {2} {5} {3} {4}" and throw my argument on to the end?
Simply *ability* to put the arguments in any order is my concern. Of course
I'm never going to do it, but I'm going to have to work on code where other
people have done it.
I don't personally want to see the file / function / line numbers in my
logging. It's fine if that's an option that other people can enable if they
want it. There's going to be a growth in the size of our text for the constant
strings for every log point having its filename and function, but it will
probably not be significant (maybe the strings can be coalesced, I wouldn't bet
one way or the other.)
If formatv could take something a LOT closer to printf, I'd be better with it.
Something like the python string formatters would be a real improvement - just
%d for base 10 numbers, not having to worry about the size of the argument in
the format string, for instance, and would still be readable & understandable
by any C programmer out there.
If we're going to start using this alternate logging scheme, eventually there
will be a push to use it everywhere, or someone will go through all the other
classes in the code base and switch it out without consultation. We need to
all sign on to this idea before it goes into the code base at all.
https://reviews.llvm.org/D27459
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
