ignore printf

Discussion in 'C Programming' started by iC and iC++, Dec 17, 2010.

  1. iC and iC++

    iC and iC++ Guest

    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,
     
    iC and iC++, Dec 17, 2010
    #1
    1. Advertising

  2. On Dec 17, 8:46 pm, "iC and iC++" <> wrote:
    >  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
    }

    }
     
    Cristian-Matei Toader, Dec 17, 2010
    #2
    1. Advertising

  3. iC and iC++

    Rich Webb Guest

    On Fri, 17 Dec 2010 10:46:31 -0800 (PST), "iC and iC++"
    <> wrote:

    > 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.

    --
    Rich Webb Norfolk, VA
     
    Rich Webb, Dec 17, 2010
    #3
  4. iC and iC++

    BartC Guest

    "iC and iC++" <> wrote in message
    news:...
    > 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.

    --
    Bartc
     
    BartC, Dec 17, 2010
    #4
  5. iC and iC++

    iC and iC++ Guest

    On Dec 17, 2:25 pm, pete <> wrote:
    > iC and iC++ wrote:
    >
    > >  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..

    >
    > /* 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 */
    >
    > --
    > pete


    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?
     
    iC and iC++, Dec 17, 2010
    #5
  6. "iC and iC++" <> writes:
    > On Dec 17, 2:25 pm, pete <> wrote:

    [...]
    >> #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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Dec 17, 2010
    #6
  7. iC and iC++

    Seebs Guest

    On 2010-12-17, pete <> wrote:
    > 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
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
     
    Seebs, Dec 17, 2010
    #7
  8. iC and iC++

    Walter Banks Guest

    iC and iC++ wrote:
    >
    > 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..
    --
    Walter Banks
    Byte Craft Limited
    http://www.bytecraft.com
     
    Walter Banks, Dec 17, 2010
    #8
  9. iC and iC++

    Ian Collins Guest

    On 12/18/10 11:06 AM, Walter Banks wrote:
    >
    >
    > iC and iC++ wrote:
    >>
    >> 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.


    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.

    --
    Ian Collins
     
    Ian Collins, Dec 17, 2010
    #9
  10. iC and iC++

    Chris H Guest

    In message <
    s.com>, iC and iC++ <> writes
    > I am developing C code on a micro controller.


    Which micro and which compiler?


    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris H, Dec 17, 2010
    #10
  11. iC and iC++

    iC and iC++ Guest

    On Dec 17, 4:48 pm, pete <> wrote:
    > iC and iC++ wrote:
    >
    > > On Dec 17, 2:25 pm, pete <> wrote:
    > > > #ifdef DEBUG_ON
    > > > #define MY_ASSERT(A) assert(A)
    > > > #else
    > > > #define MY_ASSERT(A)
    > > > #endif

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

    >
    > It makes MY_ASSERT be equal to no code.
    >
    > > 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..

    >
    > 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.
    >
    > --
    > pete


    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..
     
    iC and iC++, Dec 17, 2010
    #11
  12. iC and iC++

    BartC Guest

    "pete" <> wrote in message
    news:...
    > BartC wrote:
    >>
    >> "iC and iC++" <> wrote in message

    >
    >> > 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.

    >
    >> #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 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");

    --
    Bartc
     
    BartC, Dec 18, 2010
    #12
  13. iC and iC++

    Walter Banks Guest

    Ian Collins wrote:
    >
    > On 12/18/10 11:06 AM, Walter Banks wrote:
    > >
    > >
    > > iC and iC++ wrote:
    > >>
    > >> 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.

    >
    > 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..
     
    Walter Banks, Dec 18, 2010
    #13
  14. iC and iC++

    Jorgen Grahn Guest

    On Fri, 2010-12-17, Seebs wrote:
    > On 2010-12-17, pete <> wrote:
    >> 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.


    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

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Dec 18, 2010
    #14
  15. iC and iC++

    Rich Webb Guest

    On Fri, 17 Dec 2010 20:25:49 -0500, pete <> wrote:

    >iC and iC++ wrote:
    >
    >> 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..

    >
    >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.

    --
    Rich Webb Norfolk, VA
     
    Rich Webb, Dec 18, 2010
    #15
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ben
    Replies:
    4
    Views:
    646
    Martin Ambuhl
    Jun 26, 2004
  2. Arthur J. O'Dwyer

    Ignore argument to 'printf'?

    Arthur J. O'Dwyer, Apr 2, 2005, in forum: C Programming
    Replies:
    10
    Views:
    824
    Dave Thompson
    Apr 11, 2005
  3. whatluo

    (void) printf vs printf

    whatluo, May 26, 2005, in forum: C Programming
    Replies:
    29
    Views:
    1,309
  4. azza

    printf affects following printf/s

    azza, Oct 17, 2010, in forum: C Programming
    Replies:
    0
    Views:
    452
  5. Rob Meade
    Replies:
    6
    Views:
    293
    Rob Meade
    Mar 1, 2004
Loading...

Share This Page