Advertisements

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:

Advertisements

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

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

(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"

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.

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.

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.

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

"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__)

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

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.

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.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!