Understood, we need to be able to log if "any" bits are set. > On Jan 20, 2022, at 2:18 PM, Jim Ingham <jing...@apple.com> wrote: > > > >> 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