Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   Macro expansion (http://www.velocityreviews.com/forums/t738354-macro-expansion.html)

sandeep 11-18-2010 09:18 PM

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

Stefan Ram 11-18-2010 09:30 PM

Re: Macro expansion
 
sandeep <nospam@nospam.com> 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«).


Ian Collins 11-18-2010 09:35 PM

Re: Macro expansion
 
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

Seebs 11-18-2010 09:45 PM

Re: Macro expansion
 
On 2010-11-18, Ian Collins <ian-news@hotmail.com> 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-nospam@seebs.net
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.

Default User 11-18-2010 09:46 PM

Re: Macro expansion
 

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnlj4qxq1l.fsf@nuthaus.mib.org...
> sandeep <nospam@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.



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



Keith Thompson 11-18-2010 09:47 PM

Re: Macro expansion
 
sandeep <nospam@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?

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <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"

Ben Pfaff 11-18-2010 09:51 PM

Re: Macro expansion
 
sandeep <nospam@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.


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

Stefan Ram 11-18-2010 09:55 PM

Re: Macro expansion
 
ram@zedat.fu-berlin.de (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 )«?


ImpalerCore 11-18-2010 09:55 PM

Re: Macro expansion
 
On Nov 18, 4:46*pm, "Default User" <defaultuse...@yahoo.com> wrote:
> "Keith Thompson" <ks...@mib.org> wrote in message
>
> news:lnlj4qxq1l.fsf@nuthaus.mib.org...
>
> > 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 ...

Tim Rentsch 11-18-2010 09:58 PM

Re: Macro expansion
 
sandeep <nospam@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.


I don't think we should wait - I'm ready to decry that suggestion
right now.


All times are GMT. The time now is 01:27 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.