From: Paul Eggert > Any decent compiler will generate exactly the same > code for both. No shifts or OR will be done at > runtime -- they'll all be done at compile time. > For example: > [...]
Yes, while I tend to underestimate them, I do understand compile-time expression evaluation and dead-code elimination, and I'll admit that a "decent compiler" can optimize out all the stuff in here which irritates me so much. However, as I explained before, "one of the advantages of using the C preprocessor as it was intended to be used is that one doesn't need to _care_ whether the compiler proper can optimize away some useless code, because it will never see that useless code." That's still true, and not caring is, to me, still valuable. > [...] on both x86-64 and x86 (with GCC 4.7.0 -O2). My concept of portability extends beyond Intel CPU chips and GCC. >From time to time, for example, I've used a bundled C compiler on HP-UX, which has been (intentionally) crippled to the extent of disabling the "-O" option(s). > [...] looking at the resulting assembly language code. Some nice, cool day when I find no better ways to spend my time, ... > I realize that continuing this discussion is almost certainly > pointless, [...] The evidence for that one is piling up all around us, but ... As I recall, the original argument presented for eschewing use of the C preprocessor here went something like the following: > Generally speaking we prefer 'if (xxx)' to '#if xxx' where > either will do, because the former is easier to read and > reason about. I'm left wondering whether, say, "var = con1 << 31 << 1 | con0" offers so great an improvement in clarity over, say, "var = con" that it justifies the preference for "()" over "#" here. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547
