[Development] QLog ( Work on qDebug and friends)

[wolfgang.beck at nokia.com]

Well I think I can change the macro name very easy but we can't name it qDebug.
So maybe qDebugCat or somethink like this.
But I think the macro is very necessary special if you develop for devices they don't have the capacity of a desktop machine.

Cheers, 
  WB




-----Original Message-----
From: Koehne Kai (Nokia-MP/Berlin) 
Sent: Saturday, February 11, 2012 1:44 AM
To: BRM; Beck Wolfgang (Nokia-MP/Brisbane); development at qt-project.org
Subject: RE: [Development] QLog ( Work on qDebug and friends)

> -----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