K03B%DHBRRZ41.BITNET@CUNYVM.CUNY.EDU (03/13/91)
Anybody out there interested in a new C/C++ preprocessor?
I'm currently working on a C++ compiler which translates C++ to
(K&R) C and is supposed to run on every machine with a working C
compiler that supports a `certain standard'.
As part of that project I'm now concerned with the preprecessor
and the idea came to my mind to take the chance and implement one that
includes all kinds of nice features we always wanted to see.
But what features are that?
Well of course I thought of a few (and stole some from the GNU
preprocessor) but I'm sure there's more to it. To give you an idea of
what I'm thinking of, take these for example:
- Warnings are (optionally) given for #undef's which clear macros that
are not defined - this may help track down some kinds of errors.
- A special file may be created that contains a list of all included
files (I first saw this as a feature of the GNU preprocessor and I liked
it immediately).
The features must be well suited for a preprocessor and of
course they may *not* violate the standard behaviour. What I'm really
looking for are (not neccesarily ingenious) ideas that could
be useful in certain situations - the kind of `Ooooh I wish my
preprocessor could do this for me now!'
Because of the fact that a C++ preprocessor is very much the
same as an ANSI C preprocessor I will only write one program that can
handle both. So your suggestions may refer to C features and C++
features as well.
Any ideas? I can't wait to hear about them!
My address: Michael Brandt
K03B@DHBRRZ41 (BITNET)
(no internet address - sorry)
--
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.meranda@cis.ohio-state.edu (deron meranda) (03/18/91)
In article <1991Mar14.163125.1245@iecc.cambridge.ma.us> <K03B%DHBRRZ41.BITNET@CUNYVM.CUNY.EDU> writes: > I'm currently working on a C++ compiler which translates C++ to > (K&R) C ... > > As part of that project I'm now concerned with the preprecessor > and the idea came to my mind to take the chance and implement one that > includes all kinds of nice features we always wanted to see. > [...] > - Warnings are (optionally) given for #undef's which clear macros that > are not defined - this may help track down some kinds of errors. Actually, according to the ANSI C standard, it is quite legal to #undef preprocessor symbols that have never been #define'd. In fact this is a desirable feature, since #undef's are frequently used to hide or erase macro definitions to get at the actual standard library functions. In most cases, defining macros is up to the implementation, so any standard code can not possibly know if the #undef is useless. (I don't have my copy of the standard with me now, so no sections numbers, sorry) In order to "catch" these extra #undef's anyway, you'll probably have to implement a full preprocessor, which can be quite tricky to do correctly. I don't know about C++, but I highly suggest that you forget about K&R and get the ANSI C standard (see FAQ of comp.std.c). The preprocessor "language" is not as straight-forward as it first appears. It is actually fairly complex! > - A special file may be created that contains a list of all included > files (I first saw this as a feature of the GNU preprocessor and I liked > it immediately). You might also want to output preprocessor info for each file, such as which files define certain macros, etc. ? I have also seen a compiler which allowed as an option, that each header file is at most included one time. If two or more #include's are given for the same file, the later #include's are ignored. > [...] > Any ideas? I can't wait to hear about them! > [...] You may want to output warnings for any uses of C trigraph escapes (the ??x shortcuts) as some old code may accidentaly have them embeded in strings. Also beware of the new ## token concatenation operator. Before this came into existence, old preprocessors used an empty comment /* */ which they would just delete. The standard says they are to be changed into ONE space. This is a common incompatibility problem which could be fixed easily with a simple preproc. switch. You might want to buzz the people over at comp.lang.c and comp.lang.c++. I'm sure lots of those people have big "dreams" :) Deron E. Meranda ( meranda@cis.ohio-state.edu ) -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.