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

[Pavel Labath via lldb-dev]

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.

pl