> On Jan 20, 2022, at 11:26 AM, Pavel Labath <pa...@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 <pa...@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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
