Re: #if vs #ifdef

[tomas]

On Thu, Mar 27, 2003 at 07:48:05AM -0500, Dale P. Smith wrote:
> On Thu, 27 Mar 2003 00:18:08 -0600
> Rob Browning <address@hidden> wrote:
> 
> >                                              Their argument is that all
> > reasonable compilers will generate the same code either way, and using
> > C code rather than the preprocessor can substantially improve the
> > readability of the code and allow the C compiler to do more thorough
> > analysis of all code paths.
> 
> I agree that nested #if's are a horrible thing to wade through, and it
> makes sense to do this.  On the other hand, aren't there modes in emacs
> that allow you to hide the #if'ed out code?  That would improve
> readability far more than if (..).
> 
> I don't understand how it better for the compiler though.  I would think
> using #if's effectively edits the code out of the way before the
> compiler has a chance to look at it.  Using if (..) gives the compiler
> useless work to do.  How is theis better?

This disadvantage is at the same time the advantage (how zen-ish ;-)

The `iffed-out' code gets shaken by the compiler on a regular basis
and some silly bugs get spotted earlier...

(ISTR a funny example for this. Hmmm... Ah, yes, it was in the PostgreSQL
mailing list: the code contained an #elsif instead of an #elif. As long
as the corresponding #if was false, no one noticed, since the preprocessor
dutifully jumped to the matching #endif).

Of course sometimes you can't avoid #if -- when you are sorting out things
which have to be done at compile or link time (e.g. differences in headers,
libraries and such).

Regards
-- tomas