From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: big program with macros
Date: 17 Aug 2000 15:17:45 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 64
Message-ID: <8ngvmp$hr2$1@nets3.rz.RWTH-Aachen.DE>
References: <8ndkcu$lt8$1 AT info DOT cyf-kr DOT edu DOT pl> <8ne316$jmi$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <8ngd0u$nsv$1 AT info DOT cyf-kr DOT edu DOT pl> <8ngk5n$c2c$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <8ngta7$27b$1 AT info DOT cyf-kr DOT edu DOT pl>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: nets3.rz.RWTH-Aachen.DE 966525465 18274 137.226.32.75 (17 Aug 2000 15:17:45 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 17 Aug 2000 15:17:45 GMT
Originator: broeker@
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

"Rafał Maj" <r_maj AT poczta DOT onet DOT pl> wrote:

> Of course, it's stupid to print out every debug information.

Exactly.

[...]
> so I can define at begining of program array of names of functions, with I
> want to be debugged
>   const char* classes_to_dbg_to_cerr[] = {"cMyClass"};
>   const char* classes_to_dbg_to_disk_file[] = {"cGfxDriver"};

I.e. you have to recompile at least part of your program whenever you
want to debug a different class. In that case, why not use more finely
grained preprocessor methods to do more of that job?

The problem you currently face is caused by *all* debug statements
being present in the code of the program, even if they aren't
currently used (because their class isn't listed in
classes_to_debug_...).  Situations like this are what conditional
compilation was invented for.  You can reproduce much of it by use of
constants, in C++, but in the case at hand, the decisions will still
be made at runtime, because the compiler doesn't know at compile time
what strings are in your classes_to_debug_ array, so it cannot predict
the outcome of the find_... method.

Instead, I'ld set up a #define DEBUG_THIS_CLASS 1 in the header file
for the class, and conditionally activate DBG statements based on it.
The conditional definition of DBG could be in a separate header file.
Roughly like the method implemented in <assert.h>, and the NDEBUG
macro.

Or you could have a central 'debugflags.h' that collects such
#defines, and include that everywhere.  As is, you're stuffing your
code with debug-output statements that aren't ever executed. That's a
waste of execution time and program size.

> I think, that this debugging strategy isn't so bad after all ?

It's not exceptionally bad, but not particularly good, either, IMHO.

Another question that keeps popping up in my mind, as we discuss this:
why not use a proper debugger, instead of trying to do it by hand?
printf()-style debugging is sometimes necessary, and there are some
gurus who claim that it's all the debugging you'll ever need. 

It's so much easier to make sense out of variable contents and other
information like it if you can observe exactly what you want, at any
given point of execution of the program and of your analysis of the
problem.  A debugger lets you do that without wading through megabytes
of debug output that turns out not to be needed most of the time, and
without having to recompile everytime your analysis has led you closer
to the problem, and you need to look at other variables to make the
next step.







-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.