[Development] QLog ( Work on qDebug and friends)

BRM bm_witness at yahoo.com
Thu Feb 9 16:16:29 CET 2012

> From: "kai.koehne at nokia.com" <kai.koehne at nokia.com>

>> -----Original Message-----
>> From: Beck Wolfgang (Nokia-MP/Brisbane)
>> I think this was a very good idea so I've tried it but I've run into one important
>> problem.
>> If I use this trick I have to call the overloaded function in QMessageLogger:
>> e.g.
>> 1. void debug(QMessageCategory category, const char *format, ...); and 2.
>> QDebug debug(QMessageCategory category);
>> The first function is ok but the 2. one needs to return a QDebug object.
>> In this case I have to do a lots of overhead e.g. function call and creating
>> object after I can check if the category should be logged or not.
>> So better having a other named macro which I can do
>> #define qLog(category) \
>>    If(!logging_enable);    \
>> Else QMessageCategory(....).debug()
>I see. You'll indeed need something like that if you want to define which category to log or not with the help of the macro expander.
>You might still get half-way there performance wise though by giving QDebug a boolean "active", and check for it in the various operator<<, e.g.
>  inline QDebug &operator<<(qint64 t)        { if (!active) return *this; stream->ts << QString::number(t); return maybeSpace(); }
>If everything is inlined, and the various overloads of operator<< that people can implement do the check too, this should mostly come down to just in a couple of if (false) ... being executed.
>Anyhow, a more basic question I have is whether we want the filtering by category be done at runtime (e.g. in a central message handler), or at compile time (like your solution seems to be based on). Maybe there's place for both, but I thought the idea for the Qt libraries was to avoid the need for recompiles ...

If the performance is not penalized and the logging is not done overboard, then I would suggest doing so at Run Time so that the various categories can be enabled/disabled as desired for debugging purposes.
That said, there may be a place for having a compile time option to entirely disable it too - e.g. for distributions and commercial (Digia) binary releases to be able to completely disable it on release builds.



More information about the Development mailing list