Previous mail
Next mail
Unformatted/full headers
Overview 10 days
Subject
Date
Thread
Author
From: Frank Heckenbach
Subject: Brief comments / additions to docs
Date: 14 Oct 2004, 17:33:28
Grant Jacobs wrote: > No chance you can allow the user to define a preprocessor as a > command-line option, then anyone who wants to can feed the code > through the C (or other) preprocessor? This could have a other uses > to people who want their code preprocessed by their own means. That's already possible, and I don't think GPC needs any particular support for it. Just let the preprocessor write its result to a temp file/pipe and let GPC read from that file/stdin(`-'). You might need `-x Pascal' (or here, perhaps, rather `-x Preprocessed-Pascal') if the temp file (or stdin obviously) does not have one of the known Pascal file name suffixes. With correctly set-up Makefiles or whatever (mostly a one-time job) it could be done quite automatically AFAICS. It's quite the same way that program generators such as lex and yacc are usually invoked (though calling them preprocessors would be a little understatement). > Reminds me I wrote a Pascal preprocessor. Forget why, though! (I'm > thinking in part here that although I can currently do push a single > source file though the preprocessor, to compile a whole project like > by first preprocessing it, I'd have to compile everything to .o > files, then link them as I won't have access to pulling in things via > 'uses' the way the Pascal compiler does. It'd be better for the > compiler to feed each source code through my choice of pre-processor > on my behalf. Follow my meaning?) OK, then it would be job for the `gp' utility which is going to replace automake. Since I've yet to add user configuration to gp, this might be a point to consider. (In fact, I've thought about something like that WRT to lex and yacc, though no concrete ideas yet.) > As I'm sure you already know, one of the key uses for varargs is so > that you can blindly pass on argument lists without having to > consider their syntax, e.g. the arguments to printf (in C). Sure. That's why I'm considering them at all. Currently, my plan is, when I get there, I'll see how difficult is it to implement them. If not, I'll just do it, otherwise let's see again ... > >BTW, about the C syntax, what does `__VA_ARGS__' actually stand for? > >I'm wondering if (if we do it in the end) we shouldn't allow to > >define a parameter name for the varargs instead of having such an > >(ugly IMHO) "magic" name. > > Not sure precisely, but most likely something along the lines of > VARiable (number of) ARGumentS. So `__VA_ARGS__' means `var. args. args.'!? ;-) Frank
Previous mail
Next mail
Unformatted/full headers
Overview 10 days
Subject
Date
Thread
Author
| Author | Subject | Date |
|---|---|---|
| Grant Jacobs | Brief comments / additions to docs | 14 Oct 2004, 23:16:00 |
Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.
Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.
This page was created by Crystal 0.999 (Linux 2.4.27/i686).