#ifdef WIN32 #elif WIN64 #endif

Question

I have come across some example code that goes like this:

#ifdef WIN32
   ...
#elif WIN64
   ...
#endif

In an #ifdef block, is it actually legal to use #elif to mean #elif defined?

Cooperation

Answer 1

No, it shouldn't be. That's not to say that some obscure C compiler wouldn't accept it as such, but it isn't part of the C standard.

Normally, for something like this you would use either #elifdef FOO (which I've never actually seen in production code) or #elif defined(FOO) (like you mentioned).

This code appears to be working in a odd way; it's rather first checking if WIN32 is defined, then checking if WIN64 is nonzero.

Ex

Thanks for the clarification. (It seems, hoewever, that the Visual Studio resource editor doesn't like either workaround, and simply needs #elif without argument). – Cooperation

Interesting. Perhaps Visual Studio's .rc files just have their own (completely different) syntax. – Argentiferous

Assuming that WINxx is defined as 1, this code isn't strictly wrong, just weird (prob. not what they intended). Remember undefined names expand to 0 in expressions, so this is ill-typed, but valid logic. – Stentor

That's a good point, but that assumes #define WINxx 1, not #define WINxx. – Argentiferous

@Leushenko This assumption cannot be met, because afaik you can just define setting-dependent symbols in the project settings, but not give the symbols any specific value. – Cooperation

Let me rephrase that: the snippet above by itself is not strictly invalid, just inconsistent, because the constants could be defined as 1, and in that specific situation it would work. While a bad idea, it's possible that this is still what the original author assumed. (It's also possible that the constants are documented to be defined as 1 or not at all, in which case this is a bad idea with corporate approval.) – Stentor