Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #146729
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Preprocessor and "empty" substitutions |
| Date | 2019-10-09 01:58 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <87bluqhh00.fsf@bsb.me.uk> (permalink) |
| References | <qng257$6ts$1@dont-email.me> <874l0kl3sm.fsf@bsb.me.uk> <qngdgq$g7u$1@dont-email.me> <87muecjcfo.fsf@bsb.me.uk> <qnil93$g3e$1@dont-email.me> |
Andrey Tarasevich <andreytarasevich@hotmail.com> writes: > On 10/7/2019 5:41 PM, Ben Bacarisse wrote: >>> >>> we'll see that the above occurrence of macro name 'D' is ultimately >>> replaced by 'x', meaning that there is some kind of >>> _repetitive/recursive_ rescan involved. >> >> If that's how you like to think of it, then go for it. I just say that >> when a macro is expanded, that expansion is scanned for more macros. > > Well, the text of the standard seem to draw a pretty specific > distinction between how parameter values are substituted and how > nested macro invocations are substituted: Yes it does. I'm not sure what your point is or if you still have a question. Do you understand your original example now? <cut> >>> 6.10.3/9 (http://port70.net/~nsz/c/c11/n1570.html#6.10.3p9) says >>> >>> "The replacement list is then rescanned for more macro names as >>> specified below." >>> >>> I initially assumed that the term "replacement list" in this quote is >>> referring to the entire replacement list of the top-level macro. >> >> To my mind, that would be an odd interpretation. It seems obvious that >> "the replacement list" refers to the one in the definition being >> expanded. > > May be. But in that case it is not clear why wouldn't they just unify > the specification of macro parameter substitution with the > specification of macro invocation: first, exhaustively substitute > everything that can be substituted in the replacement list and only > then plant the result into the target location. That would produce a macro processor with very different semantics. Why do you think it would be better? The scan on the replacement text allows the expansion to use following tokens like this: #define f g #define g(x) <x> f(1) -- Ben.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Preprocessor and "empty" substitutions Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-10-07 12:03 -0700
Re: Preprocessor and "empty" substitutions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-07 21:05 +0100
Re: Preprocessor and "empty" substitutions Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-10-07 15:16 -0700
Re: Preprocessor and "empty" substitutions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-08 01:41 +0100
Re: Preprocessor and "empty" substitutions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-09 01:58 +0100
Re: Preprocessor and "empty" substitutions Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-10-08 11:41 -0700
Re: Preprocessor and "empty" substitutions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-09 06:34 -0700
csiph-web