3B2 cpp #ifdef + #include

[Ray Butterworth]

In article <2023 at pasteur.Berkeley.Edu>, sarge at sham.Berkeley.EDU (Steven Sargent) writes:
> #else vms
> do something else
> #endif vms
> 
> The new improved cpp prints warnings about "tokens after directive
> (ignored)" after the #else and #endif lines.  Not fatal to the
> compilation, but distracting to look at, and no help.  (Yes, I can
> sed my source and fix the damn things -- certainly
> #endif /* vms */
> is an acceptable solution.  But why do they bother?)

They bother because it is nice to be warned if you entered something
that looks like it means something but doesn't.  There is nothing
worse (well not really) than software that silently ignores input that
it doesn't understand.

A better example would be:
    #ifdef vms vax
Did you really mean:
    #if defined(vms) && defined(vax)
or perhaps:
    #if defined(vms) || defined(vax)
In fact, most CPPs take it to mean:
    #ifdef vms /*vax*/

I for one certainly appreciate it when CPP warns me that it has
ignored something that I didn't explictly mark as a comment.

Similarly, how would you like it if on some system
prompt-> mail jerome laurence maurice
only sent mail to the first name on the list and silently
ignored Larry and Moe?
Designing a program that only looks at the first argument
and silently ignores the rest would be really silly right?


Also, as a matter of style,
   #ifdef vax       or #if defined(vax)
   #else /*vax*/
   #endif /*vax*/
isn't nearly as good as
   #ifndef vax      or #if !defined(vax)
   #else /*vax*/
   #endif /*vax*/
If the "if" and the "end" are far apart, the comments around the
   #else /*vax*/
   ... machine specific code ...
   #endif /*vax*/
certainly make it look to someone that has to maintain your code
that the enclosed section is the code intended for use when "vax"
IS defined, not when it ISN'T defined.