Re: Feature idea for gcc

[Björn Stein <bstein at physics dot uq dot edu dot au>]

Martin Schaffner wrote:
> The extension would allow one to write `#use "foo.c"' instead
> of `#include "foo.h"'. If the preprocessor would hit such a
> directive, it would call an external program which would create
> an appropriate header file for the source file `foo.c', and
> include it. This would free the programmer from the task of
> writing a header file for every source file.

Are you aware that for your feature idea no gcc patch is needed?

It would seem much more maintainable to have your proposed pre-preprocessor as 
a separate application that creates the .c and .h files from your sources. 
That need not be any less automated than having it integrated into gcc -- 
think a few lines in your Makefile for gnu make.

If you're set on avoiding make, maybe gcc could have an option to specify an 
external preprocessor, or even chain it before its normal one? A patch to add 
this might be sensible. However, it doesn't even require changes in gcc as 
you could just as well write a wrapper script.


There's another very good reason not to include your non-standard preprocessor 
in gcc: Frankly, it'll never become a standard, even if some people start to 
use it; we don't need yet another c language specification, either. Since you 
won't be writing just for gcc, you'll distribute your source code after your 
pre-preprocessor has digested it. So why have a compiler written for a 
non-standard language extension for which hardly anyone will ever have code?


Björn Stein


P.S.: Martin, your actual idea, of course, is good. So good that maybe 
somebody has implemented it already -- possibly not as an autoomated 
preprocessor but as a manually executed tool to generate .h files only when 
new definitions have been added to the .c file (then using a syntax 
compatible with existing c compilers). Have you searched for that yet?