Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: goodbye cpp ??? (macros vs. inline functions)
Message-ID: <6590076@hplsla.HP.COM>
Date: 5 Dec 88 18:43:41 GMT
References: <3637@pt.cs.cmu.edu>
Organization: HP Lake Stevens, WA
Lines: 62

>     <	/* code for UNIX systems only */
>  <	/* code for MSDOS systems only */
> 
> You're right, and most compilers do this. But you miss the point. Not all
> porting problems can be solved this simply. As a trivial example:
> 
> #if COMPILER_A
> 	typedef long double abc;
> #elif COMPILER_B
> 	typedef double abc;
> #else
> 	}}}}	/* cause a syntax error */
> #endif
> 
> Basically, there's a lot more differences between compilers than can
> be handled with an if(0)...else... construct.

Maybe, but let me ask a devil's advocate type question:

WHY NOT allow conditional compilation of typedefs?  What would it take
to allow the language to do this?

[suffice to say, I'm assuming that the conditional expressions must 
 eval to compile time constants.]

If the cpp "hack" above is necessary to write portable programs,
as indeed it seems to be, then why not admit this is a capability
required in everyday programming practice -- and make it part of
the language?

I do not doubt there is always going to be weird stuff that is best
handled by cpp, or some more qualified preprocessor, but shouldn't
"everyday" programming needs be built into a language?  As opposed
to forcing you to "fake" a capability by using a preprocessor?

Wouldn't, for instance:

class intObject
{
    int anInt;

    if (TEST | DEBUG)
    {
        char * name;
        ...
    }
    ...
}


-- wouldn't this be a reasonable way to be able to specify variables
and functionality that are only needed for testing and debugging a 
class, that you don't want to provide in the finalized software?
        
And if you start hacking cpp to force users of cpp to follow the 
syntax of the language -- aren't you really admitting that that
capability would best be built into the language in the first place?