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

Groups > comp.lang.c > #101235 > unrolled thread

Macro Expansion

Back to article view | Back to comp.lang.c

Contents

  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

Page 1 of 4  [1] 2 3 4  Next page →

#101235 — Macro Expansion

I've knocked up a short script program to implement CPP macro expansion. 
It works with many of the examples I've tried, but I have little 
confidence that whatever I end up with will always work, as I'm guessing 
at the algorithms needed.

The descriptions I've seen of the process seem to me ambiguous and 
difficult to understand (maybe they're striving to be as cryptic as the 
language they are describing!).

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)

In the expansion of M(10,XX):

* The token sequence '10' is used for argument x

* The token sequence 'XX' is used for argument y.

* Start with the replacement token list as defined for M:

     x y #x y ## z M(a,b) W

* Replace x and y with their arguments, expanding, stringifying
   or combining as needed:

    10 20 "10" XXz M(a,b) W

   Here, argument XX was separately macro expanded to 20 before replacing
   the first y. The second y has ## so is not expanded.

* After this substitution, the token list is scanned for macro calls to
   expand. M is a macro call, but is the same name as the macro
   currently being expanded, so maps to itself (and the (a,b) following
   are just tokens).

* That leaves XXz and W macros to expand, which now results in:

    10 20 "10" 99 M(a,b) W+W+XX+x

* 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.

* The re-scanning looking for new macros continues until there are no
   macro expansions.

* The # and ## processing, for # and ## present in the original
   replacement list, is only done once. What's not clear what it will do
   with # and ## introduced as the result of macro expansion (if that is
   even possible).

* (And, # used within a macro replacement list where there are no
   parameters, is just a hash token. This seems to be implied in the
   C standard.)

Summary:

* Macro arguments need only be expanded once (K&R2 A12.3 suggests this
   could be done on each substitution, when a parameter occurs more than
   once).

* Substitution of parameter names, and #/## processing, is done once.
   Parameter names are not substituted again

* Repeated passes are now done to expand macro calls, until there are
   no macro calls left to expand.

* A macro name A can be expanded several times in one pass, but then A
   is not expanded again if re-encountered in subsequent passes.

Phew!

-- 
Bartc

[toc] | [next] | [standalone]

#101238

On Saturday, January 7, 2017 at 4:36:08 PM UTC-2, Bart wrote:
[...]
     #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)
> 
> In the expansion of M(10,XX):
> 
> * The token sequence '10' is used for argument x
> 
> * The token sequence 'XX' is used for argument y.

My understanding is that XX is expanded before calling M.
So 20 is used for argument y and also "XX" is used for y in 
case #y or ##y. 

"6.10.3.1 Argument substitution

1 After the arguments for the invocation of a function-like 
macro have been identified, argument substitution takes place. 
A parameter in the replacement list, unless preceded by a # or
## preprocessing token or followed by a ## preprocessing token 
(see below), is replaced by the corresponding argument after 
all macros contained therein have been expanded."

I am not sure if this makes difference. 
I can't find a sample, but doing before is similar 
of function call semantics.

[toc] | [prev] | [next] | [standalone]

#101256

Thiago Adams <thiago.adams@gmail.com> writes:

> On Saturday, January 7, 2017 at 4:36:08 PM UTC-2, Bart wrote:
> [...]
>      #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)
>> 
>> In the expansion of M(10,XX):
>> 
>> * The token sequence '10' is used for argument x
>> 
>> * The token sequence 'XX' is used for argument y.
>
> My understanding is that XX is expanded before calling M.

It isn't.

<snip>
> I am not sure if this makes difference. 
> I can't find a sample, but doing before is similar 
> of function call semantics.

Macros are not like functions so it's probably helpful to avoid the term
"call" for a macro expansion.

#define X Y
#define M(a) #a
M(X)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#101240

In article <o4rcbl$4cp$1@dont-email.me>, BartC <bc@freeuk.com> wrote:

> It works with many of the examples I've tried, but I have little 
> confidence that whatever I end up with will always work, as I'm guessing 

Then use m4 or some other proper macro processor.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Free the Amos Yee one.
Yeah, too bad about your so-called life. Ha-ha.

[toc] | [prev] | [next] | [standalone]

#101242

On 07/01/2017 19:45, Siri Cruise wrote:
> In article <o4rcbl$4cp$1@dont-email.me>, BartC <bc@freeuk.com> wrote:
>
>> It works with many of the examples I've tried, but I have little
>> confidence that whatever I end up with will always work, as I'm guessing
>
> Then use m4 or some other proper macro processor.

How is that going to help implementing a C pre-processor?

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#101245

In article <o4ri8d$pqj$2@dont-email.me>, BartC <bc@freeuk.com> wrote:

> On 07/01/2017 19:45, Siri Cruise wrote:
> > In article <o4rcbl$4cp$1@dont-email.me>, BartC <bc@freeuk.com> wrote:
> >
> >> It works with many of the examples I've tried, but I have little
> >> confidence that whatever I end up with will always work, as I'm guessing
> >
> > Then use m4 or some other proper macro processor.
> 
> How is that going to help implementing a C pre-processor?

t.c:    t.cm4
    m4 <t.cm4 >t.c

t.o:    t.c
    cc -o t.o t.c

Just add another build step before compiling.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Free the Amos Yee one.
Yeah, too bad about your so-called life. Ha-ha.

[toc] | [prev] | [next] | [standalone]

#101247

On 07/01/2017 20:23, Siri Cruise wrote:
> In article <o4ri8d$pqj$2@dont-email.me>, BartC <bc@freeuk.com> wrote:
>
>> On 07/01/2017 19:45, Siri Cruise wrote:
>>> In article <o4rcbl$4cp$1@dont-email.me>, BartC <bc@freeuk.com> wrote:
>>>
>>>> It works with many of the examples I've tried, but I have little
>>>> confidence that whatever I end up with will always work, as I'm guessing
>>>
>>> Then use m4 or some other proper macro processor.
>>
>> How is that going to help implementing a C pre-processor?
>
> t.c:    t.cm4
>     m4 <t.cm4 >t.c
>
> t.o:    t.c
>     cc -o t.o t.c
>
> Just add another build step before compiling.

or I could just use gcc -E. But I'm trying to understand the process so 
I can implement it myself.

(I can't use anyone else's code because mine has to be very fast and it 
needs to be integrated. I'm also trying to reduce external dependencies 
not add yet more of them!)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#101249

In article <o4rj55$tdk$1@dont-email.me>, BartC <bc@freeuk.com> wrote:

> On 07/01/2017 20:23, Siri Cruise wrote:
> > In article <o4ri8d$pqj$2@dont-email.me>, BartC <bc@freeuk.com> wrote:
> >
> >> On 07/01/2017 19:45, Siri Cruise wrote:
> >>> In article <o4rcbl$4cp$1@dont-email.me>, BartC <bc@freeuk.com> wrote:
> >>>
> >>>> It works with many of the examples I've tried, but I have little
> >>>> confidence that whatever I end up with will always work, as I'm guessing
> >>>
> >>> Then use m4 or some other proper macro processor.
> >>
> >> How is that going to help implementing a C pre-processor?
> >
> > t.c:    t.cm4
> >     m4 <t.cm4 >t.c
> >
> > t.o:    t.c
> >     cc -o t.o t.c
> >
> > Just add another build step before compiling.
> 
> or I could just use gcc -E. But I'm trying to understand the process so 
> I can implement it myself.
> 
> (I can't use anyone else's code because mine has to be very fast and it 
> needs to be integrated. I'm also trying to reduce external dependencies 
> not add yet more of them!)

Doctor! Doctor! It hurts when I do this.

Then stopping doing that.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Free the Amos Yee one.
Yeah, too bad about your so-called life. Ha-ha.

[toc] | [prev] | [next] | [standalone]

#101274

On 01/ 8/17 09:31 AM, BartC wrote:
> On 07/01/2017 20:23, Siri Cruise wrote:
>> In article <o4ri8d$pqj$2@dont-email.me>, BartC <bc@freeuk.com> wrote:
>>
>>> On 07/01/2017 19:45, Siri Cruise wrote:
>>>> In article <o4rcbl$4cp$1@dont-email.me>, BartC <bc@freeuk.com> wrote:
>>>>
>>>>> It works with many of the examples I've tried, but I have little
>>>>> confidence that whatever I end up with will always work, as I'm guessing
>>>>
>>>> Then use m4 or some other proper macro processor.
>>>
>>> How is that going to help implementing a C pre-processor?
>>
>> t.c:    t.cm4
>>      m4 <t.cm4 >t.c
>>
>> t.o:    t.c
>>      cc -o t.o t.c
>>
>> Just add another build step before compiling.
>
> or I could just use gcc -E. But I'm trying to understand the process so
> I can implement it myself.
>
> (I can't use anyone else's code because mine has to be very fast and it
> needs to be integrated. I'm also trying to reduce external dependencies
> not add yet more of them!)

Are you implying that all current implementations are deliberately slow?

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#101290

On 08/01/2017 01:42, Ian Collins wrote:
> On 01/ 8/17 09:31 AM, BartC wrote:

>> (I can't use anyone else's code because mine has to be very fast and it
>> needs to be integrated. I'm also trying to reduce external dependencies
>> not add yet more of them!)
>
> Are you implying that all current implementations are deliberately slow?

Not deliberately. But even if they are quite fast, it's not going to 
help matters if you need to invoke a separate program, which reads the 
source code, tokenises and preprocesses it, then writes the result back 
/as text/ to a file, ready for your program to tokenise it again!

And then, within the /same invocation/ of your program, which is still 
running as it is processing multiple sources, you have to re-invoke the 
same external program to do the same thing on another file, but now it 
has to reprocess the same include files which your program could have 
cached and pre-tokenised.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#101241

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.

I think they forget that was as well as the tiny number of people who 
may have to implement pre-processors (and who can then forget all the 
details immediately afterwards), many more people have to use this 
language! To devise macros, and for others to try and understand them. 
And they have to know all this.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#101250

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.

[toc] | [prev] | [next] | [standalone]

#101261

On 07/01/2017 20:42, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>> 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.

Who was responsible for standardising such a complicated macro language? 
I can't believe most C programmers are aware of all arcane details.

> 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,

No, if I got it wrong, tell me!

  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>

This introduces new problems. Just take this:

  #define X T
  #define T X
  T

How does it manage to not keep expanding indefinitely? The simplest case 
is taken care of:

  #define T T

by being explicitly mentioned (somewhere or other). For the T=>X, X=>T 
example, I can remember a 'topmost' macro name, and avoid expanding that 
even deep inside an unrelated macro expansion. But with this tweak of 
your example:

  #define X Y
  #define Y X
  #define T X Y

Now it's X=>Y, Y=>X that threatens to go on forever. I can't add these 
names to the list of names that have been expanded, as that is local to 
each level of macro. I might need to propagate a whole sequence of 
'topmost' macro names to each level.

This only applies to the recursive expansion of one specific macro. It 
doesn't apply to expansion of individual macros in a macro argument, 
which are processed independently with their own 'name-space' (of a 
propagated stack of macro names, and local list of names that have been 
processed).

Yikes. I guess whoever devised this scheme didn't think too much about 
efficiency in implementing it. To say nothing of people being able to 
predict the exact behaviour whenever they write or read macros.


-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#101264

On 01/ 8/17 11:50 AM, BartC wrote:
> On 07/01/2017 20:42, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> 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.
>
> Who was responsible for standardising such a complicated macro language?
> I can't believe most C programmers are aware of all arcane details.

They aren't, which is why they avoid them!

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#101266

On Saturday, January 7, 2017 at 10:59:26 PM UTC, Ian Collins wrote:
> On 01/ 8/17 11:50 AM, BartC wrote:
> > On 07/01/2017 20:42, Ben Bacarisse wrote:
> >> BartC <bc@freeuk.com> writes:
> >
> >>> 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.
> >
> > Who was responsible for standardising such a complicated macro language?
> > I can't believe most C programmers are aware of all arcane details.
> 
> They aren't, which is why they avoid them!
> 
Macros have token paste syntax which for the most part is best
avoided. Occasionally it is possible to produce a scheme which
looks neat to use. The snag is that when these systems fall over,
the maintaining programmer is left with a confusing mess.

All you really need is

#define ACONSTANT 299792458

and

#define trivial(a,b) ((a) == (b) ? (a) + 2 : (a) + 1)

one to keep magic numbers out of code, the other to allow type-agnostic
inline functions.

[toc] | [prev] | [next] | [standalone]

#101272

On Saturday, January 7, 2017 at 4:50:11 PM UTC-6, Bart wrote:
> Who was responsible for standardising such a complicated macro language? 
> I can't believe most C programmers are aware of all arcane details.

The language was in wide use prior to the Standard, and the Committee decided
that it should try to come up with a single set of rules which was consistent
with as many implementations as possible, rather than formulate a couple of
much simpler sets of rules--one for programs and one for implementations--such
that all programs that abide by the first set will be processed identically by
all implementations that abide by the second.

If code written for one implementation relies upon a construct working a
certain way, and code written for another implementation relies upon that
construct working some other way, the solution shouldn't be to mandate that
all implementations interpret the construct in some particular way (which
would break at least some programs), but rather deprecate the use of the
construct as having either meaning in favor of (possibly added) constructs
for which no contrary meaning exists.

Both kinds of existing code  could then continue to be used on the
implementations that support them, while being explicitly recognized as
deprecated and non-portable, while new code could then use constructs
which were unambiguous.

[toc] | [prev] | [next] | [standalone]

#101920

supercat@casperkitty.com writes:

> On Saturday, January 7, 2017 at 4:50:11 PM UTC-6, Bart wrote:
>> Who was responsible for standardising such a complicated macro language?
>> I can't believe most C programmers are aware of all arcane details.
>
> The language was in wide use prior to the Standard, and the
> Committee decided that it should try to come up with a single set
> of rules which was consistent with as many implementations as
> possible, [...]

Your view of the history is mistaken.  See the Rationale
document.

[toc] | [prev] | [next] | [standalone]

#101983

On Sunday, January 15, 2017 at 11:56:05 PM UTC-6, Tim Rentsch wrote:
> supercat writes:
> > The language was in wide use prior to the Standard, and the
> > Committee decided that it should try to come up with a single set
> > of rules which was consistent with as many implementations as
> > possible, [...]
> 
> Your view of the history is mistaken.  See the Rationale
> document.

You mean this part?

| The X3J11 charter clearly mandates the Committee to codify
| common existing practice.  The Committee has held fast to
| precedent wherever this was clear and unambiguous.  The vast
| majority of the language defined by the Standard is precisely
| the same as is defined in Appendix A of The C Programming
| Language by Brian Kernighan and Dennis Ritchie, and as is
| implemented in almost all C translators.  (This document
| is hereinafter referred to as K&R.) 

If all implementations that accept a construct treat it the same way, I
would regard the precedent as establishing a clear and unambiguous meaning
for that construct, whether or not all platforms are capable of accepting
it.  If some platforms accept it and others don't, precedent would suggest
that platforms should be allowed to accept or reject the construct at their
leisure, but if they accept it they would have to process it like existing
implementations do.

If all platforms should be able to support the construct cheaply and without
breaking any existing code, that combined with the presence of the construct
in sufficient code may constitute sufficient justification to overturn the
precedent that says compilers are not *required* to support the construct,
since the Committee intended that some compilers should require updates to
conform to the new standard.

The concept of respecting precedent, however, would seem to require much
greater justification in cases where it would break code that exploits a
useful construct which has a clear and unambiguous meaning, and that a
significant number of existing implementations accept.  Do you feel that
substantial justification should be unnecessary, or that it was provided?

[toc] | [prev] | [next] | [standalone]

#102848

supercat@casperkitty.com writes:

> On Sunday, January 15, 2017 at 11:56:05 PM UTC-6, Tim Rentsch wrote:
>> supercat writes:
>>> The language was in wide use prior to the Standard, and the
>>> Committee decided that it should try to come up with a single set
>>> of rules which was consistent with as many implementations as
>>> possible, [...]
>>
>> Your view of the history is mistaken.  See the Rationale
>> document.
>
> You mean this part?
>
> | The X3J11 charter clearly mandates the Committee to codify
> | common existing practice.  The Committee has held fast to
> | precedent wherever this was clear and unambiguous.  The vast
> | majority of the language defined by the Standard is precisely
> | the same as is defined in Appendix A of The C Programming
> | Language by Brian Kernighan and Dennis Ritchie, and as is
> | implemented in almost all C translators.  (This document
> | is hereinafter referred to as K&R.)

No I meant this part:

| Existing code is important, existing implementations are not.

[toc] | [prev] | [next] | [standalone]

#102868

On Tuesday, January 31, 2017 at 10:51:53 AM UTC-6, Tim Rentsch wrote:
> supercat writes:
> 
> > On Sunday, January 15, 2017 at 11:56:05 PM UTC-6, Tim Rentsch wrote:
> >> supercat writes:
> >>> The language was in wide use prior to the Standard, and the
> >>> Committee decided that it should try to come up with a single set
> >>> of rules which was consistent with as many implementations as
> >>> possible, [...]
> >>
> >> Your view of the history is mistaken.  See the Rationale
> >> document.
> >
> > You mean this part?
> >
> > | The X3J11 charter clearly mandates the Committee to codify
> > | common existing practice.  The Committee has held fast to
> > | precedent wherever this was clear and unambiguous.  The vast
> > | majority of the language defined by the Standard is precisely
> > | the same as is defined in Appendix A of The C Programming
> > | Language by Brian Kernighan and Dennis Ritchie, and as is
> > | implemented in almost all C translators.  (This document
> > | is hereinafter referred to as K&R.)
> 
> No I meant this part:
> 
> | Existing code is important, existing implementations are not.

As I intended the term "consistent", if X always yields 1, while Y may
arbitrarily yield 1 or 2, the behavior of X is consistent with that of
Y, but not vice versa.  Perhaps some other term would have been better?

A new implementation which processes existing code in a fashion that is
inconsistent with the old one will likely break that code.  Preserving
the functionality of existing code thus requires that new implementations
behave in a fashion consistent with the old ones.

Preserving existing implementations, by contrast, would require that the
Standard refrain from defining behaviors in cases where existing
implementations did not, i.e. it must ensure that the behaviors of all
existing platforms remain consistent with any requirements it might impose.

In any case, what you're saying fits my intended point, which is that if
there existed implementations that usefully supported a construct, forbidding
that construct without sound justification would violate the charter.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web