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

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

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

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.

commented: Point taken. I'll source better in the future. +13

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.

Thanks guys!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.