Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: net.lang.c Subject: Re: ANSI proposal for preprocessor strings Message-ID: <5194@utzoo.UUCP> Date: Sat, 9-Mar-85 19:25:37 EST Article-I.D.: utzoo.5194 Posted: Sat Mar 9 19:25:37 1985 Date-Received: Sat, 9-Mar-85 19:25:37 EST References: <9058@brl-tgr.ARPA> Organization: U of Toronto Zoology Lines: 32 > >The ANSI C standard wants to support TOKENIZED preprocessing. > >The character-string based kludges possible with the Reiser CPP > >do not fit into this concept. > > I don't see what the problem is. You have to deal with strings > specially anyway to handle \n, et. al., right? So, at the same time, > divide it up into tokens and see if any match the macro parameters. > Note that you only have to do this if the string is in a parametered > macro definition, so the overhead shouldn't be too bad. The trouble is that these two operations (escape processing and macro handling) often take place at quite different times. I know of at least one compiler (admittedly, an obscure one) which doesn't really deal with string escapes until code-generation time. Others deal with them right away, as the string is being scanned, well before anyone knows that it's part of a macro. Nobody's claiming that the Reiser things are impossible, just that they are awkward to do, unclean in concept, undocumented, and not widely accepted in non-Unix implementations. > Anyway, its not clear that the standard should not include something > only because it might be hard to implement in a certain manner.Why not? That's the way C has developed so far. Why change a winning way? To my mind, the "undocumented", "unclean in concept", and "not widely accepted in non-Unix implementations" parts are rather more significant. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry