I was under the impression that you could completely gaurd anything you wanted with an #if 0 . Apparently this is not the case?

I found some code that has opening /* comments but no matching closing */, and the /* seems to comment out the #endif , resulting in everything breaking:

#if 0
  if ( operatorMap[ops].first && !operatorMap[ops].second.first )
  {
    /** Example: /path/SINimage.mhd *
    outputFileName = path + ops + name + ext;
#endif

Is this expected? Is there an even stronger "definitely ignore everything between these tags"?

David

First off your missing the second */.. Try the below code.

#if 0
  if ( operatorMap[ops].first && !operatorMap[ops].second.first )
  {
    /* Example: /path/SINimage.mhd */
    outputFileName = path + ops + name + ext;
#endif

Edited 5 Years Ago by triumphost: n/a

I was under the impression that you could completely gaurd anything you wanted with an #if 0 . Apparently this is not the case?

I found some code that has opening /* comments but no matching closing */, and the /* seems to comment out the #endif , resulting in everything breaking:

#if 0
  if ( operatorMap[ops].first && !operatorMap[ops].second.first )
  {
    /** Example: /path/SINimage.mhd *
    outputFileName = path + ops + name + ext;
#endif

Is this expected? Is there an even stronger "definitely ignore everything between these tags"?

David

This just looks like a typo to me, it's easy enough to do. I suggest you change Line 4 to either "// *Example: /path/SINimage.mhd *" or "/* *Example: /path/SINimage.mhd */"

Edited 5 Years Ago by Fbody: n/a

A quick look at the preprocessor article on Wikipedia seems to hold the key.

http://en.wikipedia.org/wiki/C_preprocessor

Relevant lines...

The following are the first four (of eight) phases of translation specified in the C Standard:
Trigraph replacement — The preprocessor replaces trigraph sequences with the characters they represent.
Line splicing — Physical source lines that are continued with escaped newline sequences are spliced to form logical lines.
Tokenization — The preprocessor breaks the result into preprocessing tokens and whitespace. It replaces comments with whitespace.
Macro expansion and directive handling — Preprocessing directive lines, including file inclusion and conditional compilation, are executed. The preprocessor simultaneously expands macros and, in the 1999 version of the C standard, handles _Pragma operators.

My interpretation of this is that comments are handled BEFORE macros like #if. Comments are parsed first and turned into whitespace. Thus the /* and */ take precedence over #if and #endif.

Therefore it finds the starting /* INSIDE the #if 0 block, looks for the next */ token, and turns everything in between into spaces. That means #endif turns into whitespace. In the next step, it finds the #if 0 with no matching #endif.


Therefore this...

>> I was under the impression that you could completely gaurd anything you wanted with an #if 0

seems to not be the case since it's parsed AFTER the comments are parsed (red before green above).

Edited 5 Years Ago by VernonDozier: Adding some color

My interpretation of this is that comments are handled BEFORE macros like #if. Comments are parsed first and turned into whitespace. Thus the /* and */ take precedence over #if and #endif.

That's my interpretation as well, except from the standard's specified phases of translation instead of Wikipedia.

Comments
Point taken. I'll source better in the future.

I'm not saying this is the best way to do what you want, but you can #ifndef out a block of code:

//#define TESTING

#ifdef TESTING
void Test(){ //<-- inactive pre-processor block.
}
#endif
#ifndef TESTING
void Real(){ //<-- Active code.
}
#endif

I'm not saying this is the best way to do what you want, but you can #ifndef out a block of code:

//#define TESTING

#ifdef TESTING
void Test(){ //<-- inactive pre-processor block.
}
#endif
#ifndef TESTING
void Real(){ //<-- Active code.
}
#endif

That's not the problem. david already knows how to do that, that's essentially what he's trying to do. The problem is that the block/milti-line comment started inside the pre-processor conditional block wasn't closed properly so it was messing up the pre-processor blocking.

Edited 5 Years Ago by Fbody: n/a

This question has already been answered. Start a new discussion instead.