Magic #if?
in [Learn C or C++]
|
Prev: Which C++ functions to get data from a website?
Next: Shape Ups,Women's Skechers Shape Ups shoes with compare prices andbest survice!
From: Keith Thompson on 7 Aug 2010 18:49 Geoff <geoff(a)invalid.invalid> writes: [...] > The compiler should ignore anything within the block bracketed by > #if/#endif, I use it all the time. Well, almost anything. Nested #if, #else, #elif, and #endif directives are still processed to determine the matching #endif. See C99 6.10.1p6 for details. > For massive meat cleaving use the editor's ability to comment selected > lines. Select the text you want to comment out, then ctrl-k ctrl-c to > comment it out. That's very editor-specific. -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <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"
From: Ian Collins on 7 Aug 2010 20:23 On 08/ 8/10 10:49 AM, Keith Thompson wrote: > Geoff<geoff(a)invalid.invalid> writes: > [...] >> The compiler should ignore anything within the block bracketed by >> #if/#endif, I use it all the time. > > Well, almost anything. Nested #if, #else, #elif, and #endif > directives are still processed to determine the matching #endif. > See C99 6.10.1p6 for details. Ah, but that's the preprocessor, the compiler propper never gets to see the code. Are you sure about the reference? 6.10.1 only has 5 paragraphs. -- Ian Collins
From: Stefan van Kessel on 7 Aug 2010 21:26 On 8/8/2010 2:23 AM, Ian Collins wrote: > On 08/ 8/10 10:49 AM, Keith Thompson wrote: >> Geoff<geoff(a)invalid.invalid> writes: >> [...] >>> The compiler should ignore anything within the block bracketed by >>> #if/#endif, I use it all the time. >> >> Well, almost anything. Nested #if, #else, #elif, and #endif >> directives are still processed to determine the matching #endif. >> See C99 6.10.1p6 for details. > > Ah, but that's the preprocessor, the compiler propper never gets to see > the code. > > Are you sure about the reference? 6.10.1 only has 5 paragraphs. > Geoff was probably quoting from ISO/IEC 9899:TC3. Paragraph 6 must have been added in one of the technical corrigenda. "Each directive�s condition is checked in order. If it evaluates to false (zero), the group that it controls is skipped: directives are processed only through the name that determines the directive in order to keep track of the level of nested conditionals; the rest of the directives� preprocessing tokens are ignored, as are the other preprocessing tokens in the group. Only the first group whose control condition evaluates to true (nonzero) is processed. If none of the conditions evaluates to true, and there is a #else directive, the group controlled by the #else is processed; lacking a #else directive, all the groups until the #endif are skipped." (6.10.1 p6, ISO/IEC 9899:TC3)
From: Keith Thompson on 7 Aug 2010 23:01 Stefan van Kessel <stefan.van.kessel(a)mytum.de> writes: > On 8/8/2010 2:23 AM, Ian Collins wrote: >> On 08/ 8/10 10:49 AM, Keith Thompson wrote: >>> Geoff<geoff(a)invalid.invalid> writes: >>> [...] >>>> The compiler should ignore anything within the block bracketed by >>>> #if/#endif, I use it all the time. >>> >>> Well, almost anything. Nested #if, #else, #elif, and #endif >>> directives are still processed to determine the matching #endif. >>> See C99 6.10.1p6 for details. >> >> Ah, but that's the preprocessor, the compiler propper never gets to see >> the code. >> >> Are you sure about the reference? 6.10.1 only has 5 paragraphs. >> > > Geoff was probably quoting from ISO/IEC 9899:TC3. Paragraph 6 must have > been added in one of the technical corrigenda. That was me, not Goeff. > "Each directive�s condition is checked in order. If it evaluates to > false (zero), the group that it controls is skipped: directives are > processed only through the name that determines the directive in order > to keep track of the level of nested conditionals; the rest of the > directives� preprocessing tokens are ignored, as are the other > preprocessing tokens in the group. Only the first group whose control > condition evaluates to true (nonzero) is processed. If none of the > conditions evaluates to true, and there is a #else directive, the group > controlled by the #else is processed; lacking a #else directive, all the > groups until the #endif are skipped." (6.10.1 p6, ISO/IEC 9899:TC3) I was quoting from n1256; I didn't realize the paragraph numbers had changed. In fact, paragraph 6 is the same as paragraph 5 in the original C99 standard. A new paragraph 2 was inserted, under Constraints: Each preprocessing token that remains (in the list of preprocessing tokens that will become the controlling expression) after all macro replacements have occurred shall be in the lexical form of a token (6.4). in response to DR #304, <http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_304.htm>. -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <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"
From: Geoff on 7 Aug 2010 23:20
On Sat, 07 Aug 2010 15:49:23 -0700, Keith Thompson <kst-u(a)mib.org> wrote: >That's very editor-specific. Precisely. The OP stated he was working in VS 2008 IDE. |