Executing code inside "#if 0"

Q

qazmlp

There are some blocks of C/C++ code put under
#if 0

#end if


Is there anyway to make the code inside these blocks to get executed
(may be by using some command line options)?


I am using SUN compiler.
 
J

John Howells

qazmlp said:
There are some blocks of C/C++ code put under
#if 0

#end if

Is there anyway to make the code inside these blocks to get executed
(may be by using some command line options)?

I am using SUN compiler.

No. While it is there the enclosed code will be ignored by the compiler,
so there is nothing in the executable to execute. To run the code you
will have to recompile the program without the "#if 0", or after
changing it to something like "#if 01".

John Howells
 
B

Barry Margolin

There are some blocks of C/C++ code put under
#if 0

#end if


Is there anyway to make the code inside these blocks to get executed
(may be by using some command line options)?

Why did you use "#if 0" if you meant for it to be an option you could
select at compile time? Change it to something like:

#if DEBUGGING
....
#endif

and then you can use -DDEBUGGING=1 when compiling to enable that block.
 
T

Timo Weggen

Why did you use "#if 0" if you meant for it to be an option you could
select at compile time? Change it to something like:

#if DEBUGGING
...
#endif

and then you can use -DDEBUGGING=1 when compiling to enable that block.
That's a good thing, you even can go further and use
use the symbol NDEBUG as used by the assert macro calls.
In a final/production build, -DNDEBUG is set.
 
J

Joerg Schilling

tr 0 1 <original.c >tmp.c
mv tmp.c original.c
cc original.c

... and then debug ;-)

Because you need to find all the other funny places where a '0' has been
replaced by a '1' ;-)
 
B

bd

There are some blocks of C/C++ code put under
#if 0

#end if


Is there anyway to make the code inside these blocks to get executed
(may be by using some command line options)?

Change the #if 0 to #if 1
 
E

Ed Morton

Eric said:
tr 0 1 <original.c >tmp.c

Appologies if this is getting too OT, but if you REALLY want to go this route,
then use this translation instead:

sed '/#if/s/0/1/' original.c > tmp.c

so you only translate the zeros on the "#if" lines rather than everywhere in
your program, then do a quick "diff" (or tkdiff if available) on the 2 files to
check the differences before compiling. I'd also keep a backup of original.c
before starting this process!

Ed.
 
E

Emmanuel Delahaye

In said:
There are some blocks of C/C++ code put under
#if 0

#end if


Is there anyway to make the code inside these blocks to get executed
(may be by using some command line options)?

The question is not to be /executed/ of not, but to be *compiled* or not.

The #if 0 trick is used to uncomment easily one or several lines of code.

You could also use a more clever trick that is

#ifndef DBG
#define DBG 0 /* 0 | 1 */
#endif

<...>

#if DBG
/* code to be commented out (or not) */
#endif

Now, some compilers allows you to define a macro on the command line.

Say ...

-DDBG=1
or
-DDBG=0

.... according to your needs.

I often use this trick on embedded systems to reduce the size of some library
code when parts of it are not used.
 
E

Emmanuel Delahaye

In 'comp.lang.c' said:
I wouldn't, because obviously this code and assertions are not meant to
be included at the same time.

Actually I'ld probably never use NDEBUG in my code, because this IMHO as
an option from the standard library should only be used for the standard
library.

I don't see why. It often happens that I insert assert() in my code as design
checker, and I'm glad to have it automatically commented out at release time
(final target code). Using assert() implies an implicit use of NDEBUG.
 
Z

Zoran Cutura

In comp.lang.c Emmanuel Delahaye said:
I don't see why. It often happens that I insert assert() in my code as design
checker, and I'm glad to have it automatically commented out at release time
(final target code). Using assert() implies an implicit use of NDEBUG.

You're talking about the implicit usage of NDEBUG? Me not. I mean I
don't do

#ifndef NDEBUG
/* code */
#endif

or

#if !defined NDEBUG
#endif

because I want to be able switch my code on or off separately from
assertions.
 
P

pete

Using assert() implies a use of NDEBUG.
Using assert() is an implicit use of NDEBUG.
You're talking about the implicit usage of NDEBUG?
Me not. I mean I don't do

#ifndef NDEBUG
/* code */
#endif

or

#if !defined NDEBUG
#endif

because I want to be able switch my code on or off separately from
assertions.

I think he means that the defintition of the assert macro,
depends on the value of NDEBUG at that point in code.
 

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

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,007
Latest member
obedient dusk

Latest Threads

Top