Preprocessor Trickery & tokenization

Steve Glaser steveg at hammer.UUCP
Wed Jul 4 18:16:43 AEST 1984


There seems to be no argument that the X/**/Y and QUOTE mechanisms are
ugly, non-portable, hacks.  The problem is that they fill a need in
some programs that is not easily solved with anything else in the
language (otherwise why are they so prevalent and why is there so much
discussion on net.lang.c about it?).  Some folks might say (and indeed
some of the ANSI committe members appears to be) that you should use a
"real" macro preprocessor when you run into these situations.  I don't
agree.  With another preprocessor, then I have yet another tool
required to compile the program.  This creates an additional otherwise
unrequired step when porting the program of porting the macro
preprocessor.  (I can't just use m4 cause it's part of Unix(tm) and
thus not there on many systems that I want to port to.)

The "legitimate" uses of this hack that I've seen appear when you need
an automatically generated *family* of similar names (typically
external symbols).  With C's lack of scoping in external symbols (you
have only static and global), sometimes you really need this sort of
stuff.  This feature is very common in assembler macro languages and is
a widely used assembler programming idiom.

Even compilers that do early tokenization should be able to invent new
tokens in the "preprocessor" using some kind of "token concatenation
operator".  Granted, it's a change, but a rather straightforward one.
[Larry Rossler mentioned the current suggestion is using '#' for this
as it's currently unused except as the 1st printable on a line.]

I don't have a big problem with ANY mechanism the committe chooses, as
long as they choose one.  The ISO Pascal standard is a good example of
a standard that got so "purified" by the language theorists that they
didn't leave in enough to be usable.  Granted, C is nowhere near that
situation (yet) it's obvious that if any language standard isn't
complete enough to program in, it will be extended (usually in
incompatable ways).

	Steve Glaser
	tektronix!steveg

P.S.  Of the two hacks, the QUOTE mechanism is much better than X/**/Y
as the later gives lint real problems.



More information about the Comp.lang.c mailing list