Re: Feature idea for gcc

[Martin Schaffner <maschaffner at gmx dot ch>]

On Sat, 30 Nov 2002 14:55:23 +1000 Björn Stein <bstein at physics dot uq dot
edu dot au> wrote:

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

The header file generation itself would be done by an external program, c2h.
The patch to gcc itself would be very small: At the point where the
proprocessor handles `#include', it would also handle `#use'. For `#use', it would
first call c2h, then include the generated file.

> That need not be any less automated than having it integrated into gcc -- 
> think a few lines in your Makefile for gnu make.

For small projects with no configuration needs, make wouldn't even be
necessary if `#use' and `--recursive' are implemented. Instead, one could type `gcc
-r main.c -o foo'.

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

I didn't plan to create an additional preprocessor: It makes no sense to
preprocess the source twice, first looking for `#use' and then looking for the
other preprocessor directives.
If the `#use' feature is accepted into the main gcc tree, it will become a
defacto standard, like many other c/c++ language extension in gcc. Programs
for GNU systems could use it at will (except maybe gcc itself, to avoid
bootstrapping problems).

> P.S.: Martin, your actual idea, of course, is good. So good that maybe 
> somebody has implemented it already [...] Have you searched for that yet?

The first time, not throughoutly enough. A second search brought up some
tools which could serve as a base for c2h:
cextract: http://www.idiom.com/free-compilers/TOOL/C-34.html
makeheader: http://www.hwaci.com/sw/mkhdr/



On Sat, 30 Nov 2002 17:49:01 +0100 Matthias Benkmann <matthias at
winterdrache dot de> wrote:

> On Sat, 30 Nov 2002 16:54:59 +0100 Marc Espie <espie@quatramaran.ens.fr>
> wrote:
> 
> > In C, to allow for any kind of automated API generation, one would need
> > to thoroughly annotate the source file in the first place.
> 
> Which is certainly a good idea. If you use a javadoc-like system you can
> just extract those declarations for the .h file that have a documentation
> comment. That way you're only exporting functions for which proper public
> documentation has been written, which IMHO is a very good policy.

Thanks for the suggestion! A `#pragma public' before a symbol
definition/#define/typedef would therefore be necessary for c2h to not ignore it.



On Fri, 29 Nov 2002 17:04:22 -0800 Russ Allbery <rra at stanford dot edu>
wrote:

> The dependency information is somewhat interesting, but C compilers have
> already moved very far away from being any sort of integrated development
> environment that does dependency tracking, and introducing half-hearted
> depencency features into the current system doesn't strike me as something
> likely to be very successful.

Maybe the compile-this-file-and-its-dependencies feature doesn't belong to
gcc, although it would be sexy for gcc to have a `-r' flag like rm, cp, etc.,
and easier for the newbie if only one command has to be remembered.
For such a feature we would still need the `#use' feature, though. If we
declare that it's possible to do `#use <stable_lib.h>', which would act like
`#include <stable_lib.h>', except that the programmer guarantees that the
symbols in stable_lib don't change, then dependency tracking could be completely
automated. The compile-with-deps feature would have to abort if it hit an
`#include' directive, because there it wouldn't know if the interface changed.



On Fri, 29 Nov 2002 19:56:21 -0500 (EST) dewar at gnat dot com (Robert
Dewar) wrote:

> I must say I prefer to see
> C written more in the Ada style of separating specification from
> implementation, where the header acts as the spec, the the c file as the
> implementation.

I prefer the java style, since I'm too lazy to write something twice (and
lazyness drives progress :-)
For stable interfaces, and interfaces to other projects, header files could
be explicitly created by directly calling c2h. That way users of compilers
without the `#use' feature could use (binary) libraries which use `#use' in
their projects. Or they could be created by hand.
As for comments describing the symbols, I propose the use of javadoc-like
comments in c/c++ source code. An option could tell c2h to include such
comments, nicely formatted, in the header files it creates. Other options could tell
it to output html, or texi.

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!