C function prototyping and large projects

[Wayne A. Throop]

> cramer at optilink.UUCP (Clayton Cramer)
>> gwyn at smoke.ARPA (Doug Gwyn )
>>> peter at thirdi.UUCP (Peter Rowell)
>>>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.  
>> 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.

Automatically generating one or many instances of a declaring instance
of a function from a single defning instance of a function does not
imply that the bodies of functions are written before elaborating all
the interfaces.

>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.
>> I suggest you check your methodology.
>> We don't have any problem with that on our current large project.
	
I presume that Doug means that one ought to habitually introduce
interfaces before implementations.  I quite agree.  Nevertheless, it
is still much more efficent, foolproof, and convenient to have one
contiguous patch of text to edit to change any and all things about a
function.  The fact that a compiler will catch you later if you let
multiple copies get out of sync is no consolation if you are used to
it not being physically possible to be out of sync.

Having done it both ways, I agree with Clayton.  Automatic generation
of declaring instances of things from defining instances of things is
"the only way to go" (in the sense that it is much more convenient).

--
There are two ways to write error-free programs.
Only the third one works.
                                        --- Alan J. Perlis
-- 
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw