[Development] Work on qDebug and friends - debug areas

[kai.koehne at nokia.com]

> -----Original Message-----
> From: ext Olivier Goffart [mailto:olivier at woboq.com]
> Sent: Wednesday, January 25, 2012 2:03 PM
> To: development at qt-project.org
> Cc: Koehne Kai (Nokia-MP/Berlin)
> Subject: Re: [Development] Work on qDebug and friends - debug areas
> 
> On Tuesday 24 January 2012 11:03:11 kai.koehne at nokia.com wrote:
> > Hi,
> >
> > One of the things still missing in the current debugging framework is
> > to categorize messages by area: This would allow you to enable/disable e.g.
> > debug messages for only one part of your app ...
> >
> > KDE & kDebug
> >
> > Here debug categories are basically ints, which have to be registered
> > 'kdelibs/kdecore/kdebug.areas'. You can pass your specific as an
> > argument to kDebug(..) et al., but usually you just set a define
> > (KDE_DEFAULT_DEBUG_AREA).
> >
> > + comparing int's is fast
> > - one central registry needed for debug areas (no go for custom apps?)
> 
> May I suggest we use something like qHash("MyModule") And ignore the
> fact that there are collisions. (you only would loose a bit granularity in rare
> occasions.)

I guess the KDebug::registerArea David mentioned does pretty much that. I researched a bit whether you somehow can do hashing already on compile time, but it seems not to be possible even with Cx11 :( If you're doing something like qHash you most probably don't want to do it in  every single qDebug line ...

> 
> > Log4cxx ...
> >
> > Frameworks like log4cxx
> > (http://www.360doc.com/content/09/0508/23/36491_3425784.shtml) that
> are
> > modeled after log4j use free text to define areas. Also, the areas might be
> > nested, so that "MyModule " includes "MyModule.Part" semantically, and
> you
> > can do very fine grain adjustments on what exactly to log.
> >
> > + Lots of flexibility
> > - comparing strings is slow, chances that you mistype ...
> 
> you can reduce the mistype changes my using macro or static char*
> 
> How slow is it really, compared to the cost of streaming the different types
> to string and concatenating them?

Good question. Probably it's time to do some measurements :) 

> Also qDebug will get disabled in release, right?

No, that's not the case. I used to think that too, probably because of the term 'debug'. You can define QT_NO_DEBUG_OUTPUT, QT_NO_WARNING_OUTPUT,  but that's AFAIK not done anywhere in a default Qt build.

Regards

Kai