> -----Original Message-----
> From: ext BRM [mailto:[email protected]]
> Sent: Friday, February 10, 2012 3:34 PM
> To: Beck Wolfgang (Nokia-MP/Brisbane); Koehne Kai (Nokia-MP/Berlin);
> [email protected]
> Subject: Re: [Development] QLog ( Work on qDebug and friends)
>
> > From: "[email protected]" <[email protected]> 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
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
