Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!apple!voder!kontron!optilink!cramer
From: cramer@optilink.UUCP (Clayton Cramer)
Newsgroups: comp.lang.c
Subject: Re: C function prototyping and large projects
Message-ID: <534@optilink.UUCP>
Date: 3 Oct 88 18:24:45 GMT
References: <24@motto.UUCP> <3511@boulder.Colorado.EDU> <1281@micomvax.UUCP> <8597@smoke.ARPA>
Organization: Optilink Corporation, Petaluma, CA
Lines: 29

In article <8597@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes:
> In article <435@thirdi.UUCP> peter@thirdi.UUCP (Peter Rowell) writes:
> >Minor Flame:  I do *not* understand why people seem to feel that there
> >is some moral benefit to manual maintenance of information that is
> >trivially kept correct by automatic means.  If it is OK for the compiler
> >to "automatically" check these things, what is wrong with creating them
> >automatically?
> 
> In the specific case of function prototypes, if you are following
> recommended software engineering procedure, your specification for
> function interfaces precedes writing the code to implement (or use)
> them.  Automatic generation of prototypes goes in exactly the wrong
> direction.

Amazing, though, how often the function interfaces change after you
start debugging -- and how easy it is to forget to add new function
prototypes when you add new functions.

The compiler will catch the mismatches of prototypes when you change
an existing function specification, but it's still darn annoying to
realize you need to make the change after 20 modules have recompiled,
and you have to recompile them again.

It's a bit of a nuisance setting up the make files to do it (at least
with Microsoft C), but automatic generation of function prototypes
is the only way to go.
-- 
Clayton E. Cramer
..!ames!pyramid!kontron!optilin!cramer