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