Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Macro expansion

Reply
Thread Tools

Macro expansion

 
 
Eric Sosman
Guest
Posts: n/a
 
      11-19-2010
On 11/19/2010 1:04 AM, Seebs wrote:
> On 2010-11-19, Eric Sosman<(E-Mail Removed)> wrote:
>> Any macro whose expansion produces the macro's own name is
>> well-defined today, and uncompilable under your proposal. That is,
>> any macro that relies on 6.10.3.4p2 and compiles today would be
>> uncompilable.

>
> Not so!
>
> The proposed action is re-running the preprocessor.
>
> Since the first pass consumed all the #defines, there won't be any
> more, unless the code was expanding to things which looked like #defines,
> in which case it almost certainly didn't compile now.
>
> So the further passes wouldn't *do* anything. The macro names
> would no longer be macro names, because there'd be no macro definitions
> to create macro names.
>
> The proposal is actually completely harmless to just about any real
> code -- except for possible issues with #line, I don't think it would
> have ANY effect on real programs.


Ah. On rereading sandeep's proposal, I see that I was misled
by his use of the word "recursively." With that word in view, I
somehow imagined his proposal involved recursion. Silly me.

I withdraw my objection, and join my voice to your question:
In what way is his proposal different from a no-op? He suggests
(1) running the preprocessor repeatedly, which does nothing, and
(2) condemning the repeated runs, which just makes us feel shame.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
 
 
 
Jon
Guest
Posts: n/a
 
      11-19-2010
Seebs wrote:
> On 2010-11-18, Ian Collins <(E-Mail Removed)> wrote:
>> On 11/19/10 10:18 AM, sandeep wrote:
>>> One of the serious limitations of C is the fact that macro
>>> expansion is not done recursively. Many powerful constructions
>>> would become possible if this was allowed. It is also something
>>> that often trips up novices in the language.

>
>>> I would suggest that in the next release of the ISO Standard, it is
>>> decried that the preprocessor shall be run repeatedly. In fact it
>>> shall be run n times until the nth run does not change the source
>>> file.

>
>> Why? Anything that encourages preprocessor overuse should be
>> avoided!

>
> I think at this point, it is safe to say that sandeep is just
> trolling us.
>
> Think about the Stopped Clock. No one could possibly come up with
> this many suggestions which are this bad without doing it on purpose.
>


You must think very highly of yourself to keep on suggesting that people
have nothing better to do with their time than troll here. You sound like
a broken record.


 
Reply With Quote
 
 
 
 
Jon
Guest
Posts: n/a
 
      11-19-2010
Peter Nilsson wrote:
> sandeep <(E-Mail Removed)> wrote:
>> Default User writes:
>>> "Keith Thompson" <(E-Mail Removed)> wrote
>>>> sandeep <(E-Mail Removed)> writes:
>>>>> One of the serious limitations of C is the fact that
>>>>> macro expansion is not done recursively.

>
> In what way is that a _serious_ limitation?
>
>>>>> Many powerful constructions would become possible if
>>>>> this was allowed.

>
> Perhaps, but how useful are they. The preprocessing phase
> serves a very simple purpose. It was never meant to be a
> language in it's own right. Most other languages don't even
> have one.
>



Of course though, (C++) templates are just glorified macro processing.
Some such concoction is decidedly a necessary capability of "modern"
languages. Snippets, text replacement, macros, templates... all allude to
the higher-level concept of parametric code generation. How deeply it is
integrated into the language is an important design consideration.


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-19-2010
Seebs <(E-Mail Removed)> writes:
> On 2010-11-19, Keith Thompson <(E-Mail Removed)> wrote:
>> My challenge for sandeep was to provide a concrete example of a C
>> program that would make use of his proposed new feature.

>
> As-written, no currently valid C program would be changed by it.
>
> (Because all the #defines would be gone in the resulting code, so
> there'd be no macros to expand.)


Hmm?

A C program's source is what it is before the preprocessor is invoked,
macro definitions and all. I don't see how sandeep's proposal would
change that.

Here's a currently valid C program:

#include <stdio.h>
#define foo foo
int main(void)
{
char *foo = "hello, world";
puts(foo);
return 0;
}

Under sandeep's proposal, if I understand it correctly, it would be
invalid because it would send the compiler into infinite recursion.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-19-2010
Seebs <(E-Mail Removed)> writes:
> On 2010-11-19, Eric Sosman <(E-Mail Removed)> wrote:
>> Any macro whose expansion produces the macro's own name is
>> well-defined today, and uncompilable under your proposal. That is,
>> any macro that relies on 6.10.3.4p2 and compiles today would be
>> uncompilable.

>
> Not so!
>
> The proposed action is re-running the preprocessor.
>
> Since the first pass consumed all the #defines, there won't be any
> more, unless the code was expanding to things which looked like #defines,
> in which case it almost certainly didn't compile now.
>
> So the further passes wouldn't *do* anything. The macro names
> would no longer be macro names, because there'd be no macro definitions
> to create macro names.
>
> The proposal is actually completely harmless to just about any real
> code -- except for possible issues with #line, I don't think it would
> have ANY effect on real programs.


Ah, yes, I see what you mean.

For reference, here's sandeep's original proposal:

One of the serious limitations of C is the fact that macro
expansion is not done recursively. Many powerful constructions
would become possible if this was allowed. It is also something
that often trips up novices in the language.

I would suggest that in the next release of the ISO Standard,
it is decried that the preprocessor shall be run repeatedly. In
fact it shall be run n times until the nth run does not change
the source file.

You're right, feeding the preprocessor's output back to the
preprocessor repeatedly means that all #defines are removed on the
first pass. Any references to __LINE__ are resolved on the first
pass, so line numbers should be (mostly?) unaffected. There are some
corner cases involving predefined macros, and as you say #line might
be affected somehow (I'm not going to take the time to explore that).

Note that this is still rather ill-defined. Which translation
phases constitute "the preprocessor"? Phase 1 maps source file
characters to the source character set; repeating that could
certainly cause problems on some systems. Phase 5 translates the
source character set to the execution character set in character
constants and string literals; repeating this could also cause
problems. Phase 6 concatenates adjacent string literals; because
of this, the second pass could see longer logical source lines
than the first did, possibly exceeding an implementation limit.
It can also introduce new trigraphs: "??" "/"

I've guessed that what sandeep really meant (or would have meant
if he'd thought it through) was that, rather than re-running the
entire preprocessor phase on the entire source file, the "Rescanning
and further replacement" specified in 6.10.3.4 would simply not
avoid re-expanding the name of the macro being expanded, i.e.,
drop paragraph 2.

I'm still interested in seeing a concrete example where this is
useful -- either that, or an explanation of what he really has
in mind.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      11-19-2010
On 2010-11-19, pete <(E-Mail Removed)> wrote:
>> sandeep <(E-Mail Removed)> wrote:


>> > Look, I am writing a Masters thesis and my subject of expertise
>> > is "The development of the ISO C Standard".


> You're trying to show how easy it is to change the standard.
> Your'e failing because you're wrong, it isn't easy.


I honestly have a hard time believing this is someone doing a
Master's degree in any field related to computer science, unless
it's trolling as part of a psychology experiment on software
developers.

Although... you never know...

http://chronicle.com/article/The-Shadow-Scholar/125329/

Still, it's hard to imagine anyone whose understanding of C is
so persistently, consistently, awful getting to the point of working
on a thesis about C.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      11-19-2010
On 2010-11-19, Keith Thompson <(E-Mail Removed)> wrote:
> Hmm?
>
> A C program's source is what it is before the preprocessor is invoked,
> macro definitions and all. I don't see how sandeep's proposal would
> change that.
>
> Here's a currently valid C program:
>
> #include <stdio.h>
> #define foo foo
> int main(void)
> {
> char *foo = "hello, world";
> puts(foo);
> return 0;
> }
>
> Under sandeep's proposal, if I understand it correctly, it would be
> invalid because it would send the compiler into infinite recursion.


He said to run it repeatedly until there are no changes. Obviously, he
doesn't mean running it on the same source file repeatedly, he means running
it on the output.

So.

Pass 1 produces:
#line "stdio.h" 1
<magic>

int main(void)
{
char *foo = "hello, world";
puts(foo);
return 0;
}

pass 2 doesn't change this in any way.

To make it more clear, consider:
#define foo foo

int foo;

pass 1 produces:
[blank line]

int foo;

pass 2 doesn't change this. There's no longer any #defines for the
repeated runs of the preprocessor to expand.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      11-20-2010
"Keith Thompson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...


> sandeep, can you provide a concrete example of something that
> produces one expansion in C as it currently exists, and would
> produce a better expansion under your proposal?


Possibly something like this (if you imagine a macro and #if directives can
be written like this):

#define fib(n)\
#if(n<=1)
1
#else
fib((n)-1)+fib((n)-2)
#endif

Original source: fib(5)
After pass1: fib(4)+fib(3)
After pass2: fib(3)+fib(2) + fib(2)+fib(1)
After pass3: fib(2)+fib(1)+fib(1)+fib(0) + fib(1)+fib(0) + 1
After pass4: fib(1)+fib(0) +1+1+1 + 1+1 + 1
After pass5: 1+1 +1+1+1 + 1+1 + 1
After folding: 8

There are a few problems implementing this (#if probably doesn't work that
way, for a start), but it's the sort of thing that might be possible:

int a = fib(5);

compiles to:

int a = 8;

Not sure what would happen though if you tried fib(fib(5))...

As it works now:

#define fib(n) ((n)<=1 ? fib((n)-1)+fib((n)-1))

expands fib(5) to: (5<=1 ? fib(4)+fib(3)), where fib() is undefined.

--
Bartc


 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      11-20-2010
"BartC" <(E-Mail Removed)> writes:
>#define fib(n) ((n)<=1 ? fib((n)-1)+fib((n)-1))
>expands fib(5) to: (5<=1 ? fib(4)+fib(3)), where fib() is undefined.


#define fib0 0
#define fib1 1
#define fib2 1
#define fib3 2
#define fib4 3
#define fib5 5
#define fib6 8
#define fib7 13
#define fib8 21
#define fib9 34
#define fib10 55
#define fib11 89
#define fib12 144
#define fib13 233
#define fib14 377
#define fib15 610
#define fib16 987
#define fib17 1597
#define fib18 2584
#define fib19 4181
#define fib20 6765
#define fib21 10946
#define fib22 17711
#define fib23 28657

(ISO/IEC 9899:1999 (E) requires int to only represent
positive values up to 32767 IIRC.)

 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      11-20-2010


"Stefan Ram" <(E-Mail Removed)-berlin.de> wrote in message
news:(E-Mail Removed)-berlin.de...
> "BartC" <(E-Mail Removed)> writes:
>>#define fib(n) ((n)<=1 ? fib((n)-1)+fib((n)-1))


Hmm, that should end with :1 (fib0 is 1) or :n (fib0 is 0). But it won't
work anyway...

>>expands fib(5) to: (5<=1 ? fib(4)+fib(3)), where fib() is undefined.

>
> #define fib0 0

....
> #define fib23 28657


(Or possibly up to fib46 if you assume 32-bits).

The advantage of such a macro is not bothering with tabulating all the
values. Assuming some script is written to create the list, you might as
well turn the script into a macro instead.

(Of course, as written, when calculating fib(46+), exceeding 32-bits is the
least of the problems, as it might never get that far...)

--
Bartc

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Macro expansion of '#__LINE__'? Dom Gilligan C Programming 4 11-04-2005 05:47 PM
Macro Expansion Vittal C Programming 3 03-23-2005 02:04 PM
Problem with macro expansion me C++ 1 11-09-2004 02:38 PM
Macro expansion: intercept statement interpretation Benjamin Niemann Python 3 08-26-2004 02:51 AM
A question on macro expansion Ark C Programming 3 07-22-2004 11:22 PM



Advertisments