A question on C programming style

[Arnold Geels]

In comp.lang.c you write:

>I would be interested in any remarks you folks might have about this,
>especially if you have had any experience designing or using a
>dependency detector that uses this approach.

I'll bite.  My main objection is that your program could be incorrect.
There is only one program that really knows what the dependencies are and
that is the compiler itself.  All other programs must act like the compiler,
bugs and all(!).  And the more complex they become, the more you are copying
the compiler code.

So: use your compiler to generate the dependencies.

>I have long believed that writing
>MAKE scripts by hand is both too time consuming and too unreliable.
>In one project with which I was associated, it was discovered AFTER
>the product shipped that about 14 dependencies were missing from the
>circa 500-line MAKE script.

So: use automatic dependency generators.  I think we agree here.

>One obvious advantage to this approach is that the dependency list is
>always guaranteed to be up to date.  When using a conventional
>dependency generator, there is a temptation to postpone using it.

Right.  Force the system to check the dependencies every time you
compile.

>You might think that this approach would be slower than using a
>traditional MAKE program, but it turns out that it is actually faster
>in many cases.  The MAKE program resolves dependencies one at a time.
>If ten modules need to be compiled, MAKE calls the C compiler ten
>times.  Using my dependency detector, the C compiler is called just
>once; the names of the ten modules to be compiled are passed to the
>compiler as a single parameter in the form of a "response file".

I think that when projects get so big that makefiles get too large,
dependencies become hard to find, etc., performance is no longer an issue.
You want to be sure that things are correct, and that's hard enough already.
Suppose you run into a bug. You search the code for days, and finally 
find that it is caused by an out-of-date object file that was missed by
your home-made dependency generator..  Now what do you say?

>In any case, my dependency detector program employs these performance
>improvement techniques:

> (techniques deleted)

>o   To avoid reading the entire source file for include directives,
>    the program does not read beyond a certain optional pragma
>    directive, which happens to be the same pragma directive that my
>    header file generator recognizes as marking the start of the
>    implementation section.

But the compiler DOES read beyond the pragma, and if there is an include
statement there you're hung.  You could say "bad luck," but we are talking
about tools here, and tools should make life easier, not harder.

If you are interested in this topic, here is a nice article:

%T On the design of the Amoeba Configuration Manager
%A E.H. Baalbergen
%A C. Verstoep
%A A.S. Tanenbaum
%J ACM SIGSOFT Software Engineering Notes
%V 17
%N 7
%D November 1989
%P 15-22

Cheers,

Arno1d.

 - - - - - - - - - - - - - - 
Arnold Geels
Vrije Universiteit Amsterdam
The Netherlands