[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kDebug idea
From:       Mike Richardson <mike () quaking ! demon ! co ! uk>
Date:       2002-04-01 9:08:54
[Download RAW message or body]

On Monday 01 Apr 2002 12:12 am, Cristian Tibirna wrote:
> On Sunday, 31 March 2002 12:35, Simon Hausmann wrote:
> > Hi,
> >
> > There are quite a few places where people use code like this:
> >
> > // #define DEBUG_FOO
> >
> > ...
> >
> > #if DEBUG_FOO
> > kdDebug() << "bleh" << endl;
> > #endif
>
> [cut nice solution]
>
> > What do you think?
>
> At my work we use macros (and I grew to like this way, although I was used
> to think of preprocessor abuse like of something religiously sinnful :-).
> The advantage of that is that it can be completely outcompiled in
> optimization mode, without the ugliness (and line number increase) of the
> #if prepro directives.
>
> Something like:
>
> _KDE_DEBUG("bleh\n");

I've used this sort of thing extensively in large-ish program which sometimes 
needs extensive logging. The advantage is that you can build the code in a 
variety of ways :

* Macros expand to nothing: no debug output, no overhead
* Macros expand to generate output: debug output, overhead :)
* Macros expand to "if (flag) { debug ..... }"

The last has the code size overhead, but *almost* no execution time overhead, 
and you can turn debugging on or off at run time. You can do tricks like 
_XXX_DEBUG(mask, debug ....) to get selective output (but i guess kdDebug 
handles that already), and changing debug output at run time. The last is 
useful if app produces shed-loads of debugging output, but you are only 
interested in it after some event occurs


>
> which is resumed to a printf("bleh\n"); in devel mode and to a ; in optim.
> mode.
>
> Still, we mostly use this for assertions, preconditions and postconditions
> (contract driven programming, yes) and only for programmer-side errors, not
> for user debug output.
>
> Anyways, I realize what I say is quite different, but it's interesting to
> mention, I believe (and there is something better to our debugging
> mechanisms, namely a rather sofisticated memory management checking, which
> makes tools like mmalloc or electric fence or valgrind have much less use),
> but that would be real overkill for KDE's huge code.
>
> CT

Mike

-- 
mike@quaking.demon.co.uk
http://www.quaking.demon.co.uk
http://www.thekompany.com
[prev in list] [next in list] [prev in thread] [next in thread]