From -6179507042981330438
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,765aa557d15ef5ba
X-Google-Attributes: gidf78e5,public
X-Google-Thread: fc772,a175c482da34ebf8
X-Google-Attributes: gidfc772,public
X-Google-ArrivalTime: 2003-05-03 07:17:13 PST
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news1.optus.net.au!optus!news.mel.connect.com.au!news.unimelb.edu.au!bounce-back
From: allan_w@my-dejanews.com (Allan W)
Newsgroups: comp.std.c++,comp.lang.c++.moderated
Subject: Re: Preprocessor evolution
Date: 03 May 03 14:16:40 GMT
Organization: http://groups.google.com/
Lines: 58
Approved: Fergus Henderson <fjh@cs.mu.oz.au>
Message-ID: <7f2735a5.0305021101.16c15c25@posting.google.com>
References: <652361f.0304032218.6b7a67e4@posting.google.com>
  <3e920e1f.883270640@News.CIS.DFN.DE>
  <d6651fb6.0304090204.3dec4b7@posting.google.com>
  <3E94D1A2.5070406@ilog.com.sg>
  <d6651fb6.0304110620.6f41227f@posting.google.com>
  <NJjmmaB4T9l+EwYj@robinton.demon.co.uk>
  <3e9f0d33@andromeda.datanet.hu>
  <RHqB1kAqQTo+EwzI@robinton.demon.co.uk>
  <m1u1cr4a3r.fsf@localhost.localdomain>
  <7f2735a5.0304241045.14708662@posting.google.com>
  <52f2f9cd.0305010835.b456aff@posting.google.com>
NNTP-Posting-Host: taifun.cs.mu.oz.au
X-Trace: ariel.ucs.unimelb.edu.au 1051971432 5881 128.250.34.72 (3 May 2003 14:17:12 GMT)
X-Complaints-To: news@news.unimelb.edu.au
NNTP-Posting-Date: 3 May 2003 14:17:12 GMT
X-Original-Date: 3 May 2003 06:22:42 -0400
Delivered-To: std-c++@ucar.edu
X-Submission-Address: c++-submit@netlab.cs.rpi.edu
X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated
	iQBVAwUAPrOYbkHMCo9UcraBAQGJKAH+L/zEwwuW+NfDyWd5Rx2+oczBKN41MwAv
	4EUEe2yO46KNYJvS4DDdbzctDF+pwxZGprGHQFObEkPrlxhMoro/Bw==
	=LKLw
X-Approved-For-Group: francis.moderator@robinton.demon.co.uk comp.lang.c++.moderated
X-Scanned-By: MIMEDefang 2.28
X-Spam-Status: No, hits=-4.9 required=5.0
	tests=NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01
	version=2.41
X-Auth: PGPMoose V1.1 PGP comp.std.c++
Xref: archiver1.google.com comp.std.c++:19157 comp.lang.c++.moderated:65287

google@vandevoorde.com (Daveed Vandevoorde) wrote
 > I presented a set of language extensions I'm working
 > on at the recent ACCU conference (which, BTW, turned
 > out to be a very cool event).  Somewhat unexpectedly,
 > it was also presented before a part of WG21/J16.
 >
 > I put up some notes at:
 >   http://vandevoorde.com/Daveed/News/Archives/000015.html

I found this hard to read -- not your writing style, but the HTML
page. Your style sheet explicitly forces the body of the text to
show up at 11-point font, overriding my browser's setting. On my
screen, 11-point font is very difficult to read. I had to copy it
into a word processor just to read it.

The metacode concept itself seems interesting. I'm not sure
that I would consider it a replacement for the preprocessor.
We'll still need #include, #ifdef, and so on.

Also, I wonder how many compilers are going to be able to
implement all of this. It's quite extensive -- more so than
some high-level languages. Would it be possible to implement
metacode as a separate pre-compile step? If it has to run at
the same time as the main translator, there could be
difficulties (or at least performance issues) on platforms
where the compiler is already considered a big program.

I had some trouble understanding the second example in "Code
Injection Primitives" -- the one where you inject field names.
Is that supposed to generate
     float fieldfloat;
     int   fieldint;
     char  fieldchar;
and so on for all known data types? Would that include pointers,
pointers to pointers, pointers to pointers to pointers, ad
nauseum? (If so, how would you end the infinite recursion?)
Would it include user-defined classes? (If so, and you used it
within the definition of a class -- would it include the class
still being defined?) Will the code require knowledge of the
internals of the current compiler -- how the symbol table is
laid out, and so on?

Will there be such a thing as "undefined behavior -- no diagnostic
required" for metacode functions? Since they operate at compile
time, it could easily cause the compiler itself to abort -- this
would make debugging them somewhat difficult.

I must say, I like this whole idea a lot better than some of the
contortions being used to do the same things with templates.
Especially things like is_lvalue and is_constant. I'm guessing
that typeof() would be a predefined metacode function?

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]


