Hello again, I have updated the example code to reflect some of the results from this discussion. I think we are generally converging XXX, I am going to try to summarize it here, to see if we have any issues left to discuss.
- everyone seemed to prefer the formatv-based api, so that should be the main API going forward. Printf will need to be maintained until all users are migrated. I have updated by example to use that. - there were concerns about performance characteristics of this in the case logging is disabled. I'd like to reiterate that this is one of my design goals, and the new proposed API has the same overhead (checking for nullness of a local variable) as the current one. - Related to the previous item, Jim was worried about the usage of a macro will hide the fact that macro will hide the fact that the performance impact of the logging is small. I replied that anyone caring about performance that much will be familiar with this already. I also think this is no different than what a lot of other logging systems do already -- llvm's DEBUG(), assert(), boost::log all evaluate their arguments only if they are "enabled" (whatever that meant exactly), even though the call presents itself as a simple macro. I am not sure whether this topic is closed. Does anyone want to add anything to this? - there was a discussion about automatically adding log source information. My original proposal added it unconditionally. Greg suggested we make that optional (similar to how we optionally prepend timestamp, thread id, ...). Jim was worried that adding the extra data will make hamper readability of the logs. I disagreed. Having the source information be optional sounds like a good idea (i'd propose to make it on by default, as a log of log lines don't make sense without it: "__FUNCTION__ called with signal %d" and similar). I am not sure whether this answers Jim's concerns though. Jim, what do you say to that? If this would be enough (disabling source information on a global level), then great. If not, then we can come up with a way to suppress this information on a per-call-site basis. Something like: LLGB_LOG_SUPP(log, LogInfo::Source, ...) where the second argument would be the list of things to suppress for this log line. BTW, I have done some statistics on a semi-randomly chosen file ThreadPlanCallFunction.cpp: This file contains 19 logging statements. Of those, 10 print the class name, 8 print the class and function name (of those, 7 print the *wrong* function name), and there is only two that do not print any source information. One of these prints a table of registers, so it could so it could suffer from readability problems. However, it does this by printing all registers to a temporary stream, and then printing that stream. Since the prepending would only add the source before the first line of the log, this could be another way to sidestep this problem (just output "\n" before your multi-line string). All the other log statements in this file would benefit from standardizing on the source printing IMO, as that would mean we can actually align things correctly, and visually separate the repetitive part (which is already present most of the time), and variable part. What do you think of that? - Chris suggested merging lldb and llvm logging infrastructure. I have given this some thought, and I think it is possible, although it will make the implementation more tricky. I will write a separate email about that, but I want to give it more thought (and also, the proposal might depend on the exact set of requirements we converge on here). - anything else I missed? Cheers, pl _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev