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.)