ignore printf

I

iC and iC++

I am developing C code on a micro controller.

I have a bunch of printf statements that I am using to debug my code.
Now, when I am done, i just want to be able to complile the program
and take my hex file and load it onto my chip.

This is what I did..

#define DEBUG_ON
#ifdef DEBUG_ON
#include <stdio.h>
#endif

main()
{
while(1){
//bunch of printf statements for debugging
}
}

Is there a way to make the compiler ignore the printf statements
without me having to individually go and comment them out..
like a macro of some kind..

All help is appreciated..
Thanks,
 
C

Cristian-Matei Toader

 I am developing C code on a micro controller.

I have a bunch of printf statements that I am using to debug my code.
Now, when I am done, i just want to be able to complile the program
and take my hex file and load it onto my chip.

This is what I did..

#define DEBUG_ON
#ifdef DEBUG_ON
#include <stdio.h>
#endif

main()
{
while(1){
//bunch of printf statements for debugging

}
}

Is there a way to make the compiler ignore the printf statements
without me having to individually go and comment them out..
like a macro of some kind..

All help is appreciated..
Thanks,
You can use the #ifdef DEBUG_ON and #endif directives inside your
code. For instance in your case:

#define DEBUG_ON
#ifdef DEBUG_ON
#include <stdio.h>
#endif

main()
{

while(1){
#ifdef DEBUG_ON
//bunch of printf statements for debugging
#endif
}

}
 
R

Rich Webb

I am developing C code on a micro controller.

I have a bunch of printf statements that I am using to debug my code.
Now, when I am done, i just want to be able to complile the program
and take my hex file and load it onto my chip.

This is what I did..

#define DEBUG_ON
#ifdef DEBUG_ON
#include <stdio.h>
#endif

main()
{
while(1){
//bunch of printf statements for debugging
}
}

Is there a way to make the compiler ignore the printf statements
without me having to individually go and comment them out..
like a macro of some kind..

A common way of doing this is

[yourheader.h]
#ifdef DEBUG_ON
#include <stdio.h>
#define DPRINTF(x) printf x
#else
#define DPRINTF(x)
#endif

[yourfile.c]
#define DEBUG_ON // or comment-out to turn 'm off
// or define on the command line, makefile, etc. as desired
#include "yourheader.h"
....
DPRINTF(("got 0x%04X\n", retval));
....etc...

Just remember that DPRINTF needs two pairs of parens.
 
B

BartC

iC and iC++ said:
I am developing C code on a micro controller.

I have a bunch of printf statements that I am using to debug my code.
Now, when I am done, i just want to be able to complile the program
and take my hex file and load it onto my chip.

This is what I did..

#define DEBUG_ON
#ifdef DEBUG_ON
#include <stdio.h>
#endif

main()
{
while(1){
//bunch of printf statements for debugging
}
}

Is there a way to make the compiler ignore the printf statements
without me having to individually go and comment them out..
like a macro of some kind..

#ifdef DEBUG_ON
#define DPRINTF 1
#else
#define DPRINTF 0
#endif

#define dprintf(...) if (DPRINTF) printf(__VA_ARGS__)

....

dprintf("Testing %d, %d, %d\n",1,2,3);

But you have to use dprintf (or some such name) instead of printf.

If you want to use printf(), you might try something like:

#ifndef DEBUG_ON
#define printf(...)
#endif

but this will suppress *all* printf statements in the module when DEBUG_ON
is undefined.
 
I

iC and iC++

/* BEGIN new.c */

#define DEBUG_ON

/*
#undef DEBUG_ON
*/

#ifdef DEBUG_ON
#include <stdio.h>
#include <assert.h>
#define MY_ASSERT(A) assert(A)
#else
#define MY_ASSERT(A)
#endif

int main(void)
{
    for (;;) {
        /*
        ** bunch of printf statements for debugging
        */
        MY_ASSERT(printf("%d\n", 1));
        MY_ASSERT(printf("%d\n", 2));
        MY_ASSERT(printf("%d\n", 3));
        MY_ASSERT(printf("%d\n", 4));
        break;
    }
    return 0;

}

/* END new.c */

If I undef DEBUG_ON, what will the compiler do with MY_ASSERT.

I think #define MY_ASSERT(A) should be declared outside the DEBUG_ON
if space.

In either case, DEBUG_ON is undefined, what will happen to the printf
statemetns, i.e. are they going to be ignored or the loop will break,
it seems like the loop will quit..

The ideal solution to this problem, would something like I found on
this website..
http://www.digitalmars.com/ctg/debugstatement.html

Does anyone know how to do this?
 
K

Keith Thompson

iC and iC++ said:
#define DEBUG_ON

/*
#undef DEBUG_ON
*/

#ifdef DEBUG_ON
#include <stdio.h>
#include <assert.h>
#define MY_ASSERT(A) assert(A)
#else
#define MY_ASSERT(A)
#endif

int main(void)
{
    for (;;) {
        /*
        ** bunch of printf statements for debugging
        */
        MY_ASSERT(printf("%d\n", 1));
        MY_ASSERT(printf("%d\n", 2));
        MY_ASSERT(printf("%d\n", 3));
        MY_ASSERT(printf("%d\n", 4));
        break;
    }
    return 0;

}
[...]

If I undef DEBUG_ON, what will the compiler do with MY_ASSERT.

The MY_ASSERT macro is defined whether DEBUG_ON is defined or not.

If DEBUG_ON is defined, then the first definition takes effect:

#define MY_ASSERT(A) assert(A)

If DEBUG_ON is not defined, then the second definition takes effect:

#define MY_ASSERT(A)

Note that the replacement sequence is empty, which means that

MY_ASSERT(printf("%d\n", 1));

is replaced by

;

(the semicolon is outside the macro invocation) -- which is what you
want.
I think #define MY_ASSERT(A) should be declared outside the DEBUG_ON
if space.
Nope.

In either case, DEBUG_ON is undefined, what will happen to the printf
statemetns, i.e. are they going to be ignored or the loop will break,
it seems like the loop will quit..

If DEBUG_ON is undefined, the printf calls vanish.

I'm not at all sure why pete wrapped the calls in
for (;;) {
/* code here */
break;
}

That's an infinite loop that terminates after the first iteration; it
might as well be replaced by just:

/* code here */

Another odd thing pete did is to pass the result of printf() to
assert(), which means that the program will abort (unless NDEBUG
is defined) if printf doesn't print anything.
The ideal solution to this problem, would something like I found on
this website..
http://www.digitalmars.com/ctg/debugstatement.html

Does anyone know how to do this?

That's a built-in feature of the D language. As the web page says,
if you want to do something equivalent in C (or C++), you need to
use the preprocessor.
 
S

Seebs

But iC and iC++ said
"Now, when I am done,
i just want to be able to complile the program
and take my hex file and load it onto my chip."
iC and iC++ might not want to waste program space on a bunch of
if (0) printf(__VA_ARGS__)

I would want to check, but it's not uncommon for compilers to
optimize stuff like that away.

-s
 
W

Walter Banks

iC said:
Is there a way to make the compiler ignore the printf statements
without me having to individually go and comment them out..
like a macro of some kind..


There is an emotional thread "More on debuggers" running now
arguing for and against the use of printf's for debugging.

Our customers for the most part need to ship what they debug
and there are times when they would like to log data during
test which means the code that is shipped needs to be
able to deal with unwanted print statements.

What we did was to create a stdio library that is called exactly
like the normal stdio library functions except it creates
directives in our source level debugging information that
the debug environment can choose to use. These directives look
like predefined breakpoints with messages. The debug environment
interprets the embedded printfs in response to a breakpoint.
This means we have the ability to add printf statements to
environments that have no possibility of supporting them. The
first application that used this was a household thermostat.

The second important aspect of this is there is no generated
code for a printf. We can ship the code that was tested without
the overhead of embedded printfs and we can use printfs to display
or log data during regression testing and debugging.

All the best of the season,


w..
 
I

Ian Collins

There is an emotional thread "More on debuggers" running now
arguing for and against the use of printf's for debugging.

Our customers for the most part need to ship what they debug
and there are times when they would like to log data during
test which means the code that is shipped needs to be
able to deal with unwanted print statements.

What we did was to create a stdio library that is called exactly
like the normal stdio library functions except it creates
directives in our source level debugging information that
the debug environment can choose to use. These directives look
like predefined breakpoints with messages. The debug environment
interprets the embedded printfs in response to a breakpoint.
This means we have the ability to add printf statements to
environments that have no possibility of supporting them. The
first application that used this was a household thermostat.

The second important aspect of this is there is no generated
code for a printf. We can ship the code that was tested without
the overhead of embedded printfs and we can use printfs to display
or log data during regression testing and debugging.

That sounds very similar to Solaris dynamic tracing:

http://www.sun.com/software/solaris/ds/dtrace.jsp

Where probes in the code are only enabled when required. A great toll
for analysing applications in production environment.
 
I

iC and iC++

It makes MY_ASSERT be equal to no code.



Well, I wrote the program so that you could test run it easily
once with DEBUG_ON defined,
and then you could easily uncomment the
    #undef DEBUG_ON
macro, and test run it again.

By "easily",
I mean that it is easier to do it and see what would happen
than it is to wonder about it.

Yeah, I should have. I caught my mistake as soon as I hit send.

Thanks for clarifying the code further. Someone brought up that this
would be wasting memory space, what are your thoughts on that. I have
enough memory to waste in this case, but I actually thought once the
code is compiled with optimization option, all the statements would be
ignored..
 
B

BartC

pete said:
But iC and iC++ said
"Now, when I am done,
i just want to be able to complile the program
and take my hex file and load it onto my chip."

iC and iC++ might not want to waste program space on a bunch of
if (0) printf(__VA_ARGS__)

#ifdef DEBUG_ON
#define dprintf(...) printf(__VA_ARGS__)
#else
#define dprintf(...)
#endif

dprintf("This a debugging message...\n");
printf("...but this is a real one...\n");
 
W

Walter Banks

Ian said:
That sounds very similar to Solaris dynamic tracing:

http://www.sun.com/software/solaris/ds/dtrace.jsp

Where probes in the code are only enabled when required. A great toll
for analysing applications in production environment.

The difference is on the SUN dtrace is resolved by the same
processor that the code runs on and in our case there is no
generated code for the statements and the emulator or simulator
resolves the debug code

w..
 
J

Jorgen Grahn

I would want to check, but it's not uncommon for compilers to
optimize stuff like that away.

I would be shocked if a compiler (with the proper optimization level
turned on) /didn't/ optimize it away. It's obviously dead code.

/Jorgen
 
R

Rich Webb

In solution that I wrote, the MY_ASSERT code disappears
from the translation unit.

In the solution provided by Rich Webb, which I think I like
a little bit better than what I came up with,
the macro code also disappears from the translation unit.

The version that BartC shows, built around

#define dprintf(...) printf(__VA_ARGS__)

is probably the cleanest way to do it, but that capability was only
introduced in the C99 standard (although some compilers would have
supported it before that). The version I showed using the double
parentheses is rather uglier but should be universally available.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top