By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,825 Members | 1,254 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,825 IT Pros & Developers. It's quick & easy.

Executing code inside "#if 0"

P: n/a
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.
Nov 13 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a


qazmlp wrote:

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
Nov 13 '05 #2

P: n/a
In article <db*************************@posting.google.com> ,
qazmlp <qa********@rediffmail.com> wrote:
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.

--
Barry Margolin, ba************@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Nov 13 '05 #3

P: n/a
On Fri, 11 Jul 2003 16:21:04 +0200, Barry Margolin wrote:
In article <db*************************@posting.google.com> , qazmlp
<qa********@rediffmail.com> wrote:
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.

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.
Nov 13 '05 #4

P: n/a
In article <3F***************@sun.com>,
Eric Sosman <Er*********@Sun.COM> wrote:
qazmlp wrote:

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.


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' ;-)

--
EMail:jo***@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
sc*******@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Nov 13 '05 #5

P: n/a
bd
On Fri, 11 Jul 2003 03:47:15 -0700, qazmlp wrote:
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
--
Freenet distribution not available
Grelb's Reminder:
Eighty percent of all people consider themselves to be above
average drivers.

Nov 13 '05 #6

P: n/a
Eric Sosman wrote:
qazmlp wrote:

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.
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.
mv tmp.c original.c
cc original.c

... and then debug ;-)

(In other words, no. The compiler is obeying your orders,
and cannot be persuaded to disobey.)

--
Er*********@sun.com


Nov 13 '05 #7

P: n/a
In 'comp.lang.c', qa********@rediffmail.com (qazmlp) wrote:
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.

--
-ed- em**********@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Nov 13 '05 #8

P: n/a
In 'comp.lang.c', Zoran Cutura <zo**********@daimlerchrysler.com> wrote:
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.


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.

--
-ed- em**********@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Nov 13 '05 #9

P: n/a
In comp.lang.c Emmanuel Delahaye <em**********@noos.fr> wrote:
In 'comp.lang.c', Zoran Cutura <zo**********@daimlerchrysler.com> wrote:
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.


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.


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.

--
Z (Zo**********@daimlerchrysler.com)
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond
Nov 13 '05 #10

P: n/a
Zoran Cutura wrote:

In comp.lang.c Emmanuel Delahaye <em**********@noos.fr> wrote:
Using assert() implies an implicit use of NDEBUG.


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.
Nov 13 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.