Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #146729

Re: Preprocessor and "empty" substitutions

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>

Show all headers | View raw


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


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