Re: Ideas sought for C++ preprocessor

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

Return to the comp.compilers page.
Search the comp.compilers archives again.