Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!unmvax!ncar!boulder!sunybcs!bingvaxu!leah!itsgw!steinmetz!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.lang.c++
Subject: Re: goodbye cpp ??? (macros vs. inline functions)
Message-ID: <588@auspex.UUCP>
Date: 6 Dec 88 07:08:22 GMT
References: <3637@pt.cs.cmu.edu> <6590076@hplsla.HP.COM>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 28

>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?

Umm, err, at least in C, things like #ifdef *are* part of the language;
see recent draft ANSI C specs, for instance.  The "Reference Manual"
section of the "The C++ Programming Language" also lists them, so I
guess I'd consider them to be part of C++ as well. 

>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?

Again, the fact that some implementations of C or C++ happen to
implement those constructs by running source code through a preprocessor
and then through what some people might prefer to think of as the "real"
compiler doesn't mean they have to be implemented that way, or that
they're not part of the language.

There is some precedent, if I remember correctly, for language features
that can be considered to affect the source code seen by the "real"
compiler.  I think PL/I provide (more-or-less) equivalent capabilities,
although the syntax used more closely resembled that of PL/I than the
syntax of the "#" functions resembles that of C.  (I seem to remember
PL/I using "%" as the magic character to distinguish "pre-processor"
constructs from "real" language constructs.)