This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Feature idea for gcc


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]