[lldb-dev] Is GetLogIf**All**CategoriesSet useful?

[Greg Clayton via lldb-dev]

Understood, we need to be able to log if "any" bits are set. 

> On Jan 20, 2022, at 2:18 PM, Jim Ingham <jingham at apple.com> wrote:
> 
> 
> 
>> On Jan 20, 2022, at 11:26 AM, Pavel Labath <pavel at labath.sk> wrote:
>> 
>> On 20/01/2022 00:30, Greg Clayton wrote:
>>> I also vote to remove and simplify.
>> 
>> Sounds like it's settled then. I'll fire up my sed scripts.
>> 
>> On 20/01/2022 01:38, Greg Clayton wrote:
>>> On Jan 19, 2022, at 6:40 AM, Pavel Labath <pavel at labath.sk> wrote: 
>>>> If we got rid of this, we could simplify the logging calls even further and have something like:>> Log *log =
>>>> GetLog(LLDBLog::Process);
>>> Can a template function deduce the log type from an argument? Wouldn't this have to be:
>>> Log *log = GetLog<LLDBLog>(LLDBLog::Process);
>>> That is why I was hinting if we want to just use the enum class itself:
>>> Log *log = LLDBLog::GetLog(LLDBLog::Process);
>>> The template class in your second patch seems cool, but I don't understand how it worked without going and reading up on templates
>>> in C++ and spending 20 minutes trying to wrap my brain around it.
>> Template functions have always been able to deduce template arguments.
>> Pretty much the entire c++ standard library is made of template
>> functions, but you don't see <> spelled out everywhere. Class templates
>> have not been able to auto-deduce template arguments until c++17, and I
>> am still not really clear on how that works.
>> 
>> The way that patch works is that you have one template function
>> `LogChannelFor<T>`, which ties the enum to a specific channel class, and
>> then another one (GetLogIfAny), which returns the actual log object (and
>> uses the first one to obtain the channel).
>> 
>> But none of this is fundamentally tied to templates. One could achieve
>> the same thing by overloading the GetLogIfAny function (one overload for
>> each type). The template just saves a bit of repetition. This way, the
>> only thing you need to do when defining a new log channel, is to provide
>> the LogChannelFor function.
>> 
>>> Or do we just switch to a dedicated log class with unique methods:
>>> class LLDBLog: public Log { Log *Process() { return GetLog(1u << 0);
>>> } Log *Thread() { return GetLog(1u << 1); } };
>>> and avoid all the enums? Then we can't ever feed a bad enum or #define  into the wrong log class.
>> 
>> That could work too, and would definitely have some advantages -- for
>> instance we could prefix each message with the log channel it was going
>> to. The downside is that we would lose the ability to send one message to multiple log channels at once, and I believe that some (Jim?) value that functionality.
> 
> I think I’m just quibbling about terminology, I don’t think it’s possible for one site to send its log message to two channels in a single go.  That would be like “lldb types” and “dwarf info” for a single log statement.
> Anyway, that’s not something I see as particularly useful.
> 
> What is useful is to say “this message goes out on the lldb channel if any of these categories (“step” and “expr” for instance) is set.”  I don’t really think of that as sending the message to multiple channels, since it’s only going to go out once, but the test is broader.
> 
> But, IIUC, Greg’s proposal would also make that impossible as well, so I’m still against it…
> 
> Jim
> 
> 
>> 
>> pl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20220120/7106d3f1/attachment-0001.html>