Mail Archives: djgpp/2000/08/17/13:15:31
Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de> wrote :
> I.e. you have to recompile at least part of your program whenever you
> want to debug a different class.
I don't now yet how to write own libraries etc..., and now I'm always
recompiling all program (but on 525Mzh + 8MB ram disk it works fine)
> 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.
Yes, I have few debug options in "dbg_cfg.h", declared like #define
DBG_ECHO 1 #define DBG_LEVEL 2
When my program works correctly, I can change #define DBG_ALL 1 to
#define DBG_ALL 0 and then *ALL*
debug macros, additional variables in classes etc... aren't compile - so
program is smaller, and it's compiling and executing faster.
> 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?
[..]
> 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.
I now how to use debugger, and I now that it is much more comfortable.
However : my program is using SVGA graphics and allegro keyboard / mouse
handler, so I can't debug it like this.
> A debugger lets you do that without wading through megabytes
> of debug output that turns out not to be needed most of the time
Program can wrtie to separated files like "init.dbg", "warnings.dbg",
"mem.dbg".
Normal debug output have less then 300 lines.
Often I use macros to print statistics informations - how long it took to
load graphics files, how often program have to unload some data from memory,
etc...
- Raw text -