[Lldb-commits] [PATCH] D27459: Straw-man proposal for new logging syntax

Jason Molenda via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Fri Dec 9 04:00:13 PST 2016

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.


More information about the lldb-commits mailing list