[Development] QLog ( Work on qDebug and friends)

[kai.koehne at nokia.com]

> -----Original Message-----
> From: ext BRM [mailto:bm_witness at yahoo.com]
> Sent: Friday, February 10, 2012 3:34 PM
> To: Beck Wolfgang (Nokia-MP/Brisbane); Koehne Kai (Nokia-MP/Berlin);
> development at qt-project.org
> Subject: Re: [Development] QLog ( Work on qDebug and friends)
> 
> > From: "wolfgang.beck at nokia.com" <wolfgang.beck at nokia.com> The
> > controlling of the category will be done using a configuration file.
> > QLog contains a private class that creates a file watcher for the
> > configuration file.
> > So not only if you start the application but during runtime as well
> > the category filtering can be changed dynamically by changing the config
> file.
> > No recompiling needed with this solution.
> 
> +1.
> 
> This is a far better solution, IMHO, than the macro expansion.

Well, I think Lincoln and Wolfgang are voting for the filtering combined with a qLog() macro ...

Personally, I'm biased. It's certainly nice that

qLog("MyCategory") << expensiveOperation();

becomes almost a NOOP if logs for MyCategory aren't kept. However, adding yet another 'keyword' to the framework has a price, especially since the difference between 'qDebug(QMessageLogContext("MyCategory"))' << and a 'qLog("MyCategory") << ' is subtle.

But then again I'm not the person who can approve such a change in the first place :) So this is just my 2 cents here.

> FYI - I support a system that operates at up to 400 samples/second with
> extensive logging to a modular logging system - syslog, files, EventLog, etc.
> It doesn't seem to impact performance at all, so I don't see the issue with
> having Qt be able to filter at run-time either as Wolfgang specifies above.

Agreed, especially if you're not overdoing it with logging (which you shouldn't do in the libraries anyway).

> Ben

Regards

Kai