On Mon, Feb 9, 2009 at 12:10 PM, Sean McBride <s...@rogue-research.com> wrote: > On 2/9/09 11:24 AM, Clark Cox said: > >>> Apple's headers inconsistently use #if and #ifdef. >> >>Because #if and #ifdef will both give the proper result in this >>instance (i.e. the GCC compiler either defines __LP64__ to true, or it >>doesn't define it at all), they are interchangeable. >> >>> I recommend: >>> >>> #if defined (__LP64__) && __LP64__ >> >>FYI, there is no functional difference between: >> >>#if defined (SOMEMACRO) && SOMEMACRO >> >>and >> >>#if SOMEMACRO >> >>That is, the preprocessor treats any undefined identifier in an '#if' >>or '#elif" as if it were defined to be zero. > > I'm not a language lawyer, but I believe the latter is not guaranteed to > evaluate to 0 if the macro is not defined. However, I imagine 99% of > compilers will evaluate it to 0. gcc certainly does.
I am 100% positive that this is guaranteed by the standard: >From 6.10.1.3: "After all replacements due to macro expansion and the defined unary operator have been performed, all remaining identifiers are replaced with the pp-number 0" > This is the reason for the existance of -Wundef I believe. > >>> which will also not warn with -Wundef. >> >>My original #ifdef won't trigger this warning either > > True of course. > >>therefore it is >>the best of all options (i.e. it's concise, doesn't trigger warnings, >>and provides the correct result). > > True if __LP64__ is either defined to something or not defined at all. > This is currently the case, but I could not find docs guaranteeing > this. If it's ever defined to 0 then you'd have a problem. This would also break quite a bit of code out there. However, my #ifdef is immune to such changes, it could be defined to any value they felt like; its the presence or absence of the macro that matters. > And seeing how Apple itself sometimes uses #if and sometimes #ifdef I think > caution > is advised. The fact that the headers use both directives is evidence that it really doesn't matter which you use. > This is rather academic of course... :) Indeed :) -- Clark S. Cox III clarkc...@gmail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
