This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Feature idea for gcc
- From: Marc Espie <espie at quatramaran dot ens dot fr>
- To: maschaffner at gmx dot ch
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 30 Nov 2002 16:54:59 +0100
- Subject: Re: Feature idea for gcc
- Organization: Ecole Normale Superieure (quatramaran)
In article <809.1038615028@www62.gmx.net> you write:
>Hi,
>
>I want to create an extension to the c and c++ languages, implemented as a
>patch to gcc.
>
>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.
>
>Another advantage of the `#use' directive would be direct visibilty of
>dependencies to the compiler, which would allow for an additional
>feature to gcc:
>the compiler flag `--recursive'. This flag would tell the compiler to look at
>dependencies of the source files it has to compile, and compile those as
>well (if necessary). This would free the programmer from writing makefiles for
>projects with no configuration needs.
>
>Any feedback is welcome.
>
Well, this tends to assume .c -> .h is an automated task.
Unfortunately, it is not.
Anyone who believes otherwise is sadly misguided.
In all but the most trivial cases, crafting proper header files is an art.
Specifically, you don't want to expose more of the implementation than
strictly necessary. In many, many cases, the initial header file you write
will show too much of the implementation, and both the implementation and
the API will need reworking.
There's a reason most modern languages outside of C establish a clear
distinction between API and implementation. C leaves that burden entirely
to the programmer. I'm reasonably certain an automated tool like you suggest
wouldn't help at all. In fact, it would be very dangerous.
I've seen enough libraries where the API changed between release 1.0 and
release 2.0 because the programmers had overlooked API design as a small,
trivial detail...
In C, to allow for any kind of automated API generation, one would need to
thoroughly annotate the source file in the first place.