Debug statements

[vivek]

Hi

i have used some debug macro and called several times(hundreds) in
the code.

The purpose of the macro was to print the values at that time to the
screen

Now that i have finished debugging, i do not want to execute the
macro.

If i use

#define DEBUG1 <blank>

the code executes the statements inside the debug except that it is
not printing on the screen, which takes time.

Is there any better way(than commenting all hundreds of lines of
code)?

Thanks in Advance,
VIVEK

[vippstar@gmail.com]

Re: Debug statements

On Apr 3, 6:58 pm, vivek <gvivek2...@gma il.comwrote:

Hi
>
i have used some debug macro and called several times(hundreds) in
the code.
>
The purpose of the macro was to print the values at that time to the
screen
>
Now that i have finished debugging, i do not want to execute the
macro.
>
If i use
>
#define DEBUG1 <blank>
>
the code executes the statements inside the debug except that it is
not printing on the screen, which takes time.
>
Is there any better way(than commenting all hundreds of lines of
code)?

I believe not, unless you come up with some regex to do the commenting
for you.
You wouldn't have to do all this work now if you used a better method,
such as

int debug(void) {
#ifdef NDEBUG
/* ... */
#endif
return 0;
}

printing values is usually a poor debugging technique.
I suggest you learn to use a real debugger.
And if you decide to do so and then have a question about it, try a
newsgroup related to your debugger or debuggers in general and not clc.

[jacob navia]

Re: Debug statements

vivek wrote:

Hi
>
i have used some debug macro and called several times(hundreds) in
the code.
>
The purpose of the macro was to print the values at that time to the
screen
>
Now that i have finished debugging, i do not want to execute the
macro.
>
If i use
>
#define DEBUG1 <blank>
>
the code executes the statements inside the debug except that it is
not printing on the screen, which takes time.
>
Is there any better way(than commenting all hundreds of lines of
code)?
>
Thanks in Advance,
VIVEK

Youy should write:

#define DEBUG1(a)

This way, ALL the expression in "a" disappears.

If you write
#define DEBUG1

you eliminate the DEBUG1, leaving its argument (a) THERE!

Do not forget that the preprocessor is just a text replacement
machine

AND

It is better and less intrusive to use a real debugger



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Ben Bacarisse]

Re: Debug statements

vivek <gvivek2004@gma il.comwrites:

i have used some debug macro and called several times(hundreds) in
the code.
>
The purpose of the macro was to print the values at that time to the
screen
>
Now that i have finished debugging, i do not want to execute the
macro.
>
If i use
>
#define DEBUG1 <blank>
>
the code executes the statements inside the debug except that it is
not printing on the screen, which takes time.
>
Is there any better way(than commenting all hundreds of lines of
code)?

It may be too late now, but one way is to use extra parentheses:

#define DEBUG(x) logging_functio n x

and in the code:

DEBUG(("x = %d\n", x));

so when you need to get rid of all the code you define:

#define DEBUG(x)

and you get nothing at all.

--
Ben.

[Keith Thompson]

Re: Debug statements

Ben Bacarisse <ben.usenet@bsb .me.ukwrites:

vivek <gvivek2004@gma il.comwrites:

> i have used some debug macro and called several times(hundreds) in
>the code.
>>
>The purpose of the macro was to print the values at that time to the
>screen
>>
>Now that i have finished debugging, i do not want to execute the
>macro.
>>
>If i use
>>
>#define DEBUG1 <blank>
>>
>the code executes the statements inside the debug except that it is
>not printing on the screen, which takes time.
>>
>Is there any better way(than commenting all hundreds of lines of
>code)?

>
It may be too late now, but one way is to use extra parentheses:
>
#define DEBUG(x) logging_functio n x
>
and in the code:
>
DEBUG(("x = %d\n", x));
>
so when you need to get rid of all the code you define:
>
#define DEBUG(x)
>
and you get nothing at all.

That's necessary only if DEBUG takes a variable number of arguments
(say, if it's a wrapper for fprintf).

Suppose DEBUG1 takes a single argument, and a typical call is

DEBUG1(some_exp ression);

Then this:

#define DEBUG1

causes the call to be replaced with

(some_expressio n);

which still evaluates the expression. But this:

#define DEBUG1(arg)

makes DEBUG1 a function-like macro, so the call is replaced with just this:

;

If you have several DEBUG*() macros taking various fixed numbers of
arguments, you can define an empty function-like macro for each. If
DEBUG() is variadic, you might be able to use a C99 variadic macro
definition *if* your compiler supports it (or supports an extension
that does something similar); I'm not familiar enough with that C99
feature to comment further.

If you actually need to make several hundred changes to your source
code, some of the more advanced features of your favorite text editor
or scripting language might be helpful. Of course that's a topic for
another newsgroup.

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Robbie Hatley]

Re: Debug statements

"vivek" wrote:

i have used some debug macro and called several times(hundreds) in
the code.
>
The purpose of the macro was to print the values at that time to the
screen
>
Now that i have finished debugging, i do not want to execute the
macro.
>
If i use
>
#define DEBUG1 <blank>
>
the code executes the statements inside the debug except that it is
not printing on the screen, which takes time.
>
Is there any better way(than commenting all hundreds of lines of
code)?

What I do is use a function-like macro called "BLAT", defined
like so:

// In an included header file:
#ifdef BLAT_ENABLE
#define BLAT(X) printf ( X ) ;
#else
#define BLAT(X)
#endif

// In some source file:
#define BLAT_ENABLE
.... some code...
BLAT("Length = %f and Height = %f\n", L, H)

After debugging, change "#define BLAT_ENABLE" to "#undef BLAT_ENABLE",
and the "BLAT" statements go away.

And if you maintain, expand, or refactor the code later, and it has
bugs, just #define BLAT_ENABLE and all your BLATs are re-activated.

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant

[Ben Bacarisse]

Re: Debug statements

Keith Thompson <kst-u@mib.orgwrites :

Ben Bacarisse <ben.usenet@bsb .me.ukwrites:

>vivek <gvivek2004@gma il.comwrites:

>> i have used some debug macro and called several times(hundreds) in
>>the code.

<snip>

>>Is there any better way(than commenting all hundreds of lines of
>>code)?

>>
>It may be too late now, but one way is to use extra parentheses:
>>
> #define DEBUG(x) logging_functio n x
>>
>and in the code:
>>
> DEBUG(("x = %d\n", x));

<snip>

That's necessary only if DEBUG takes a variable number of arguments
(say, if it's a wrapper for fprintf).

Yes, and even then only if one does not have the use of C99's variadic
macros. Still, it is an old technique that is worth knowing if, for
no other reason, one might be puzzled on seeing it in existing code.

--
Ben.

[Ben Bacarisse]

Re: Debug statements

Ben Bacarisse <ben.usenet@bsb .me.ukwrites:

Keith Thompson <kst-u@mib.orgwrites :

<snip stuff about debugging>

>That's necessary only if DEBUG takes a variable number of arguments
>(say, if it's a wrapper for fprintf).

>
Yes, and even then only if one does not have the use of C99's variadic
macros. Still, it is an old technique that is worth knowing if, for
no other reason, one might be puzzled on seeing it in existing code.

.... which I see you had the foresight to mention. Sorry for the noise.

--
Ben.

[Keith Thompson]

Re: Debug statements

"Robbie Hatley" <see.my.signatu re@for.my.email .addresswrites:

Keith Thompson wrote:

[...]

>#ifdef BLAT_ENABLE
>#define BLAT(X) printf X
>#else
>#define BLAT(X)
>#endif
>>
>...
>>
>BLAT(("Lengt h = %f and Height = %f\n", L, H));
>>
>Note that I've deleted the semicolon from the macro definition.

>
That works. Thanks for the tweak! But I'd leave the semicolon
in the macro definition, not the invocation. The reason is,
that way if you "#undef BLAT_ENABLE", even the semicolon
dissappears, and the compiler just sees an empty line.

[...]

I'd definitely leave the semicolon out of the macro definition.
Without the semicolon, an invocation of BLAT has the syntax of a
function call. With your method, everything *except* a BLAT()
invocation has a semicolon. The lone semicolon that remains when
BLAT(X) reduces to nothing is harmless; it's a null statement that's
legal wherever any statement is legal.

Of course you can do whatever you like with the preprocessor, but some
things are just good habits.

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Robbie Hatley]

Re: Debug statements


Keith Thompson wrote:

"Robbie Hatley" <see.my.signatu re@for.my.email .addresswrites:

Keith Thompson wrote:

[...]

#ifdef BLAT_ENABLE
#define BLAT(X) printf X
#else
#define BLAT(X)
#endif
>
...
>
BLAT(("Length = %f and Height = %f\n", L, H));
>
Note that I've deleted the semicolon from the macro definition.

That works. Thanks for the tweak! But I'd leave the semicolon
in the macro definition, not the invocation. The reason is,
that way if you "#undef BLAT_ENABLE", even the semicolon
dissappears, and the compiler just sees an empty line.

[...]
>
I'd definitely leave the semicolon out of the macro definition.
Without the semicolon, an invocation of BLAT has the syntax of a
function call. With your method, everything *except* a BLAT()
invocation has a semicolon.

Yes. But that's why I don't do it. I like making
function-like macro invocations look DIFFERENT from actual
function calls. They're not C functions at all, they're
text-processing commands, so I prefer to remind myself of
that fact by invoking them differently. This helps me to
avoid falling into the many traps that lie in wait for
those who mistakenly think preprocessor commands are
C statements.

The lone semicolon that remains when BLAT(X) reduces to
nothing is harmless; it's a null statement that's legal
wherever any statement is legal.

Yes, it's legal, but I prefer not to leave extra semicolons
dangling about. Less cleanup work for the compiler to do
that way.

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant