Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #101250
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Macro Expansion |
| Date | 2017-01-07 20:42 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <874m1appnx.fsf@bsb.me.uk> (permalink) |
| References | <o4rcbl$4cp$1@dont-email.me> <o4ri5t$pqj$1@dont-email.me> |
BartC <bc@freeuk.com> writes:
> On 07/01/2017 18:35, BartC wrote:
>
>> Here is what I've been able to understand of the process; maybe someone
>> can tell me if it is on the right lines.
>>
>> Example:
>>
>> #define XX 20
>> #define XXz 99
>> #define W W+W+XX+x
>> #define M(x,y) x y #x y ## z M(a,b) W
>>
>> M(10,XX)
>
>> * The result is now scanned again looking for new macros to expand.
>> However, once any name (eg. M and W) has been expanded once, it is
>> never expanded again (in a subsequent pass). So only XX is changed
>> to result in:
>>
>> 10 20 "10" 99 M(a,b) W+W+20+x
>>
>> (This agrees with what gcc -E gives, apart from an extra space before
>> +x)
>>
>> * Presumably that rule also applies to parameter names, so the new x at
>> end stays as x, it's not changed to 10.
>
> I think the rule is different. Once a parameter name token such as x
> has been substituted once, a new instance of x resulting from a macro
> expansion is treated like any other identifier.
>
> Then that new x can be expanded if x is a macro name.
>
> I wish they would just state all this stuff instead of leaving people
> to either deduce it or eventually discover it for themselves.
"They" (presumably the C committee) have an obligation to be precise
rather than explanatory. It's the various books and tutorials about C
that should explain this in simpler terms. If no such thing exists -- a
lot of C tutorials are either overly simplistic or wrong -- then it's
not the fault of the C committee.
You are trying to understand it by adding rules. That's often a good
way to explain things but equally often a bad way to define things.
Your rule above ("Once a parameter name token such as x has been
substituted once, a new instance of x resulting from a macro expansion
is treated like any other identifier") is not needed in the
specification because it is a consequence of the rules that are needed.
The main fuzziness in your description comes from not explaining the
boundaries of an expansion (exactly the text from the standard you said
was not adding anything). It's not the case that the text is repeated
scanned and the anything expanded already is not expanded again. Every
macro expansion is a separate, bounded, sequence of tokens, and only
within that expansion is the expansion of the macro being expanded
ignored. I'm not suggesting you've got it wrong, but I did not find
your explanation clearer that the official one. A test:
#define X Y
#define Y T
#define T X Y
<T> => <X><Y>
<X> => <Y>
<Y> => <T>
<Y> => <T>
(using <> to delimit tokens and indentation to show nested expansions).
<snip>
--
Ben.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Macro Expansion BartC <bc@freeuk.com> - 2017-01-07 18:35 +0000
Re: Macro Expansion Thiago Adams <thiago.adams@gmail.com> - 2017-01-07 11:23 -0800
Re: Macro Expansion Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-07 21:28 +0000
Re: Macro Expansion Siri Cruise <chine.bleu@yahoo.com> - 2017-01-07 11:45 -0800
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-07 20:16 +0000
Re: Macro Expansion Siri Cruise <chine.bleu@yahoo.com> - 2017-01-07 12:23 -0800
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-07 20:31 +0000
Re: Macro Expansion Siri Cruise <chine.bleu@yahoo.com> - 2017-01-07 12:42 -0800
Re: Macro Expansion Ian Collins <ian-news@hotmail.com> - 2017-01-08 14:42 +1300
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-08 13:18 +0000
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-07 20:15 +0000
Re: Macro Expansion Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-07 20:42 +0000
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-07 22:50 +0000
Re: Macro Expansion Ian Collins <ian-news@hotmail.com> - 2017-01-08 11:59 +1300
Re: Macro Expansion Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-07 15:10 -0800
Re: Macro Expansion supercat@casperkitty.com - 2017-01-07 17:24 -0800
Re: Macro Expansion Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 21:55 -0800
Re: Macro Expansion supercat@casperkitty.com - 2017-01-16 09:06 -0800
Re: Macro Expansion Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:51 -0800
Re: Macro Expansion supercat@casperkitty.com - 2017-01-31 13:06 -0800
Re: Macro Expansion Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-03 07:49 -0800
Re: Macro Expansion supercat@casperkitty.com - 2017-02-03 12:03 -0800
Re: Macro Expansion Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-09 09:00 -0800
Re: Macro Expansion Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-08 01:37 +0000
Re: Macro Expansion Jean-Marc Bourguet <jm@bourguet.org> - 2017-01-08 10:22 +0100
Re: Macro Expansion Thiago Adams <thiago.adams@gmail.com> - 2017-01-07 12:18 -0800
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-07 20:28 +0000
Re: Macro Expansion Thiago Adams <thiago.adams@gmail.com> - 2017-01-07 12:36 -0800
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-07 22:59 +0000
Re: Macro Expansion Thiago Adams <thiago.adams@gmail.com> - 2017-01-08 00:20 -0800
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-08 13:30 +0000
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-10 14:00 +0000
Re: Macro Expansion Thiago Adams <thiago.adams@gmail.com> - 2017-01-10 07:43 -0800
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-10 17:47 +0000
Re: Macro Expansion Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-10 22:49 +0000
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-10 23:28 +0000
Re: Macro Expansion "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-10 18:51 -0500
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-11 00:06 +0000
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-10 20:30 +0000
Re: Macro Expansion Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 10:04 -0700
Re: Macro Expansion Keith Thompson <kst-u@mib.org> - 2017-04-26 12:00 -0700
Re: Macro Expansion Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 12:24 -0700
Re: Macro Expansion bartc <bc@freeuk.com> - 2017-04-26 20:12 +0100
Re: Macro Expansion Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 12:34 -0700
Re: Macro Expansion jameskuyper@verizon.net - 2017-04-26 13:46 -0700
Re: Macro Expansion Jean-Marc Bourguet <jm@bourguet.org> - 2017-01-08 10:13 +0100
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-08 13:10 +0000
Re: Macro Expansion Jean-Marc Bourguet <jm@bourguet.org> - 2017-01-08 15:51 +0100
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-08 17:17 +0000
Re: Macro Expansion supercat@casperkitty.com - 2017-01-08 11:04 -0800
Re: Macro Expansion Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-08 11:10 -0800
Re: Macro Expansion supercat@casperkitty.com - 2017-01-08 14:08 -0800
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-08 19:49 +0000
Re: Macro Expansion supercat@casperkitty.com - 2017-01-08 14:17 -0800
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-08 19:19 +0000
Re: Macro Expansion Jean-Marc Bourguet <jm@bourguet.org> - 2017-01-08 21:43 +0100
Re: Macro Expansion supercat@casperkitty.com - 2017-01-08 10:43 -0800
Re: Macro Expansion Keith Thompson <kst-u@mib.org> - 2017-01-08 12:39 -0800
Re: Macro Expansion antispam@math.uni.wroc.pl - 2017-01-08 22:54 +0000
Re: Macro Expansion "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-08 18:36 -0500
Re: Macro Expansion antispam@math.uni.wroc.pl - 2017-01-09 01:15 +0000
Re: Macro Expansion "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-08 20:49 -0500
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-08 23:53 +0000
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-09 01:11 +0000
Re: Macro Expansion antispam@math.uni.wroc.pl - 2017-01-09 01:31 +0000
Re: Macro Expansion BartC <bc@freeuk.com> - 2017-01-10 11:28 +0000
csiph-web