Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

Macro expansion

 
 
sandeep
Guest
Posts: n/a
 
      11-18-2010
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.
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      11-18-2010
sandeep <> writes:
>One of the serious limitations of C is the fact that macro expansion is
>not done recursively.


You can add additional macro processors in front of the C compiler,
which - of course - is less portable.

>Many powerful constructions would become possible if this was
>allowed.


Yes, but they might also be less readable/maintainable.

The choice of C as a language might even express that one
does *not want* such »higher-order macros«. Otherwise, one
might have chosen Lisp.

>I would suggest that in the next release of the ISO Standard,
>it is decried that the preprocessor shall be run repeatedly.


This might break existing code. However, you can implement
it yourself by calling »cpp« (the C preprocessor) in this way
(in a script with »diff«).

 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      11-18-2010
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!

--
Ian Collins
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      11-18-2010
On 2010-11-18, Ian Collins <ian-> 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.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
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
 
Default User
Guest
Posts: n/a
 
      11-18-2010

"Keith Thompson" <kst-> wrote in message
news:...
> sandeep <> writes:
>> 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.

>
> 1. How much existing code would this break?
>
> 2. Do you really want to define a language feature that can easily cause
> a compile-time infinite loop?


Has Sandeep ever had a proposed change to the language that made sense? I
decided he was a troll a long time ago, but others may feel differently.



Brian
--
Day 652 of the "no grouchy usenet posts" project.
Current music playing: "Blue Suitcase" (Erin McCarley)


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-18-2010
sandeep <> writes:
> 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.


1. How much existing code would this break?

2. Do you really want to define a language feature that can easily cause
a compile-time infinite loop?

--
Keith Thompson (The_Other_Keith) kst- <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
 
Ben Pfaff
Guest
Posts: n/a
 
      11-18-2010
sandeep <> writes:

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


Any recursive macro would recurse forever, wouldn't it?
--
"Give me a couple of years and a large research grant,
and I'll give you a receipt." --Richard Heathfield
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      11-18-2010
(Stefan Ram) writes:
>Yes, but they might also be less readable/maintainable.


Actually, I /did/ built a preprocessor system with multiple
levels of macros myself. Here are some examples of the
source code (to judge their readability for the uninitiated):

This shows a function definition: It will write the
declaration to the header file and write the definition to
the implementation file. So one needs to change the
prototype only once in the source - not twice (in the header
file and in the implementation file):

@[h@*h
wchar_t * kdtxuc( register wchar_t * target, register const wchar_t * source )
@]¨#=writehead @=h@:h libkcfh libkc.c¨$[libkc.c
{ register wchar_t * result = target; while( *target++ = *source++ ); return result; }
$]libkc.c

The next example shows two blocks, labeled by an automatic
counter c (whose value is not visible here). The »¨@=@+c«
inserts the next block at this position, so:

@[@*c
{ IPersistFile * ppf;
hres = psl->lpVtbl->QueryInterface( psl, &IID_IPersistFile, &ppf );
if( SUCCEEDED( hres ))
{ @=@+c
¨ppf~>Release()¨; }
else{ printf( "QueryInterface failed, rc(%x),%x\n", hres, GetLastError()); }}¨@]

@[@*c
{ WORD wsz[ MAX_PATH ]; MultiByteToWideChar( CP_ACP, 0, LinkName, -1, wsz, MAX_PATH );
hres = ¨ppf~>Save( wsz, TRUE ); }¨@]

becomes

@[@*c
{ IPersistFile * ppf;
hres = psl->lpVtbl->QueryInterface( psl, &IID_IPersistFile, &ppf );
if( SUCCEEDED( hres ))
{ { WORD wsz[ MAX_PATH ]; MultiByteToWideChar( CP_ACP, 0, LinkName, -1, wsz, MAX_PATH );
hres = ¨ppf~>Save( wsz, TRUE ); }¨
¨ppf~>Release()¨; }
else{ printf( "QueryInterface failed, rc(%x),%x\n", hres, GetLastError()); }}¨@]

Thus, one can write (deeply) nested blocks as a /sequence/ of blocks.

It seems that ¨...¨ also means something. Possibly, it will
expand enclosed ¨~>¨ to something, but what this is, I have
forgotten now. Maybe ¨ppf~>Release()¨ became ¨Release( ppf )«?

 
Reply With Quote
 
ImpalerCore
Guest
Posts: n/a
 
      11-18-2010
On Nov 18, 4:46*pm, "Default User" <defaultuse...@yahoo.com> wrote:
> "Keith Thompson" <ks...@mib.org> wrote in message
>
> news:...
>
> > sandeep <nos...@nospam.com> writes:
> >> 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.

>
> > 1. How much existing code would this break?

>
> > 2. Do you really want to define a language feature that can easily cause
> > a compile-time infinite loop?

>
> Has Sandeep ever had a proposed change to the language that made sense? I
> decided he was a troll a long time ago, but others may feel differently.


Yeah, but his trolling does sometimes provoke interesting discussion.
sandeep could have put a little more effort into his post, to make it
look a little bit more serious, like an example using some pseudocode
of what he intended it to do ...
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      11-18-2010
sandeep <> writes:

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


I don't think we should wait - I'm ready to decry that suggestion
right now.
 
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
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57