I like the the llvm::formatv stuff and could see using this exclusively. I am
getting scared of using streams and << the more I think about it after my
previous email since we would need to mark a log message as starting and ending
somehow and that would make things messy.
Note that our logging has many options:
(lldb) help log enable
Enable logging for a single log channel.
Syntax: log enable <cmd-options> <log-channel> <log-category> [<log-category>
[...]]
Command Options Usage:
log enable [-STagnpstv] [-f <filename>] <log-channel> <log-category>
[<log-category> [...]]
-S ( --stack )
Append a stack backtrace to each log line.
-T ( --timestamp )
Prepend all log lines with a timestamp.
-a ( --append )
Append to the log file instead of overwriting.
-f <filename> ( --file <filename> )
Set the destination file to log to.
-g ( --debug )
Enable debug logging.
-n ( --thread-name )
Prepend all log lines with the thread name for the thread that
generates the log line.
-p ( --pid-tid )
Prepend all log lines with the process and thread ID that generates
the log line.
-s ( --sequence )
Prepend all log lines with an increasing integer sequence id.
-t ( --threadsafe )
Enable thread safe logging to avoid interweaved log lines.
-v ( --verbose )
Enable verbose logging.
So we will need to be able to do each of these with each log line. Streams will
make things messy.
Greg
> On Dec 6, 2016, at 10:07 AM, Zachary Turner via lldb-dev
> <[email protected]> wrote:
>
> Merging the thread over from lldb-commits:
>
>
>
> On Tue, Dec 6, 2016 at 9:57 AM Jim Ingham via Phabricator
> <[email protected]> wrote:
> jingham added a comment.
>
> I not infrequently have some non-trivial code in the "if (log)" block that
> gathers the information that I am then going to print, or loops over entities
> printing them. Putting more complex code like that inside a macro looks
> awful and is hard to debug. I don't think that argues for not using the
> macros in the case where you are logging a simple string, but it does argue
> for keeping the old way available.
> Not arguing against keeping the old way possible, but as an aside,
> llvm::formatv() can handle many of these cases pretty nicely.
>
> For starters, it has builtin support for formatting ranges. So if you're
> ever looping over entities formatting them, as long as the entity itself has
> a formatter defined, you can simply pass it directly to formatv and it will
> do the right thing. (It has some customization support built in as well so
> you can control how to separate items).
>
> Secondly, When you have to do some work to get the value you want to format,
> you could either define a custom formatter for the type in question, and the
> formatter does all the work, or you could write a function to return the
> value you want to format, and call that in the argument list, as long as the
> return type has an associated formatter.
>
> I'm sure there will still be cases where you want to use the old method, but
> I think this would handle quite a few of them and reduce the amount of code
> you have to read / write when dealing with logging code.
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
