3 ms·

Can someone explain what #if static_cast<bool>(-1) is about? My thoughts were "that's just #if true, no?", then "wait, static_cast is not part of the prepr

Can someone explain what #if static_cast<bool>(-1) is about? My thoughts were "that's just #if true, no?", then "wait, static_cast is not part of the preprocessor, that can't work" to "wtf, it actually compiles"... Edit: As people point out, you can click on it to get context. And yeah, that one is an oof.

adzm 4y ago
> The #if statement replaces, after macro expansion, every remaining identifier with the pp-number 0. So #if static_cast<bool>(-1) is equivalent to #if 0<0>(-1), #if 0 > -1, and #if 1. Wow, I have no idea why this would ever be done.
- jcelerier 4y ago
  well it's the consequence of #if SOME_STUFF evaluating to 0 if SOME_STUFF isn't defined
- kazinator 4y ago
  > I have no idea why this would ever be done. You'd never literally write #if static_cast<bool>(-1) but it could be the result of a macro expansion.
- sudosysgen 4y ago
  Because the preprocessor doesn't know what static_cast is, so in an if it just evaluates to false as do any values that haven't been defined.
kazinator 4y ago
I suspect the point is that the preprocessor language expression syntax that is out of whack with the host languages it is integrated into. If you hoist an expression of the language proper into a preprocessing directive, you may get gibberish. This could happen by accident, particularly through layers of macros: Say you have: #if SOME_MACRO(ARG) originally, this expands to an constant expression in which everything is an integer; then someone edits the macro. Things may still compile, but the expression is gibberish, not doing what it looks like it's doing. The macro could be used in non-preprocessing contexts: int x = SOME_MACRO(X); if (SOME_MACRO(Y)) ... so that programmer might have a good reason for editing it; just they didn't notice it's also used in an #if directive.

3 ms·

Can someone explain what #if static_cast<bool>(-1) is about? My thoughts were "that's just #if true, no?", then "wait, static_cast is not part of the prepr

by MauranKilom 4y ago

adzm 4y ago
> The #if statement replaces, after macro expansion, every remaining identifier with the pp-number 0. So #if static_cast<bool>(-1) is equivalent to #if 0<0>(-1), #if 0 > -1, and #if 1. Wow, I have no idea why this would ever be done.
- jcelerier 4y ago
  well it's the consequence of #if SOME_STUFF evaluating to 0 if SOME_STUFF isn't defined
- kazinator 4y ago
  > I have no idea why this would ever be done. You'd never literally write #if static_cast<bool>(-1) but it could be the result of a macro expansion.
- sudosysgen 4y ago
  Because the preprocessor doesn't know what static_cast is, so in an if it just evaluates to false as do any values that haven't been defined.
kazinator 4y ago
I suspect the point is that the preprocessor language expression syntax that is out of whack with the host languages it is integrated into. If you hoist an expression of the language proper into a preprocessing directive, you may get gibberish. This could happen by accident, particularly through layers of macros: Say you have: #if SOME_MACRO(ARG) originally, this expands to an constant expression in which everything is an integer; then someone edits the macro. Things may still compile, but the expression is gibberish, not doing what it looks like it's doing. The macro could be used in non-preprocessing contexts: int x = SOME_MACRO(X); if (SOME_MACRO(Y)) ... so that programmer might have a good reason for editing it; just they didn't notice it's also used in an #if directive.