Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #146767
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Preprocessor and "empty" substitutions |
| Date | 2019-10-08 11:41 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <qnil93$g3e$1@dont-email.me> (permalink) |
| References | <qng257$6ts$1@dont-email.me> <874l0kl3sm.fsf@bsb.me.uk> <qngdgq$g7u$1@dont-email.me> <87muecjcfo.fsf@bsb.me.uk> |
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: * In case of parameters it states that first of all, any macro substitutions inside the parameter value are processed. And only when this process is complete (i.e. everything is exhaustively substituted) the final result is planted into the parent macro. * In case of nested macro invocations it is the other way around: the substitution list for the invoked macro is immediately planted into the parent macro, and only afterwards that planted list is rescanned for more macro invocations. This appears to be done for some specific reason. And the first reason for that distinction that come to mind is that parameters are intended to be processed out-of-context, while macro invocations are intended to be handled (rescanned) in-context (in the context of surrounding tokens). > >> I presume that what you mean is that the rescan process is done >> _locally_. > > Well, I meant what I said but it was obviously not clear. > >> 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. -- Best regards, Andrey Tarasevich
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