Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!cs.utexas.edu!hellgate.utah.edu!hamblin.byu.edu!byuvax!physc1!kla
From: kla@physc1.byu.edu
Newsgroups: comp.lang.c
Subject: Re: #define DEBUG... (using printf for debugging)
Message-ID: <103kla@physc1.byu.edu>
Date: 8 May 90 12:06:50 GMT
Lines: 60

I'm Sorry I just couln't resist this discussion. I have been using this
type of Debugging statements for quite some time with a great deal of
success. It all started when CodeView couldn't fit into the same
640K as the rest of my program, but I now use it in even my unix
programs even when I also use a source level debugger.

I tried to use debugging levels, as in:

Debug(level,("%d %c %f",a,b,c));

but found that this was too much of a regimen for me. I finally settled
for the following in a header file.

static int __bug__ = 1;

#define bug(); __bug__ = 1;
#define bugoff(); __bug__ = 0;

#ifdef DEBUG

#define Debug(cmdstr)  if(__bug__) { printf cmdstr ; fflush(stdout); }

#else

#define Debug(cmdstr)

#endif

The difference between this and the other things offered is slight, but
important for Object Oriented programming. It is the bug() and bugoff()
routines. This way you can debug a certain object WITHIN THE CONTEXT
OF A BIG REAL LIFE PROGRAM without wading through piles of similar
printouts of other already debugged modules.

The __bug__ variable is defined as statically global to each and
every module separately. This is a fine point, but it is important.

Also, if you get into the source level debugger, and you find that
there may be a problem in another module which was unexpected, you
can turn on its debugging by toggling its __bug__ variable and watching
the output for a while.

The other thing which no one has mentioned, is that this type of
statement should not be removed from production code. It is very
useful as internal documentation. If a new programmer comes on and
wants to figure out a new piece of code, he can just look at the
Debug statements to find out what was in the mind of the YoYo that
wrote it. He can also turn on the debug statements of one module
to watch how that module interacts with other parts of the program.

This could be made a lot more sophisticated as necessary. Thanks for
your attention for this little addition to the Debug lore.

One thing I haven't figured out yet. How to do this elegantly while
debugging a user interface. Nothings perfect, but a log file might
work by just redirecting stdout since most user interfaces don't
use the standard printf.

-Kelly
-Just a few bats from the belfrey.
kla@batman.byu.edu