Xref: utzoo comp.lang.c:33404 alt.religion.computers:1993 Path: utzoo!utgpu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!sugar!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.lang.c,alt.religion.computers Subject: Re: ANSI C prototypes Message-ID: <-BV6Q16@xds13.ferranti.com> Date: 3 Nov 90 18:04:28 GMT References: <1005@christopher-robin.cs.bham.ac.uk> <1906@necisa.ho.necisa.oz> <1990Nov2.030556.27759@ccu.umanitoba.ca> <1990Nov3.122432.24738@ccu.umanitoba.ca> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 24 In article <1990Nov3.122432.24738@ccu.umanitoba.ca> salomon@ccu.umanitoba.ca (Dan Salomon) writes: > Actually, include files aren't quite the same as a library of function > prototypes. The distinction is the same as between an object library, > and a file full of object modules. True, there is an efficiency consideration. I don't tend to have a single module or collection of modules that require more than a handful of files, so this hasn't been a problem. Plus, who says include files have to be stored in files? The C standard doesn't. This is an implementation detail. :-> Yeh, it's a problem, but it's not a show stopper. > In addition to the problem of > keeping the include files up to date, That is the real problem. You need a tool to extract the prototypes from a file. Beyond that, make will do the rest. > Processing all the prototypes in an include file is slower than a search > for and processing of only the ones actually needed. Precompiled include files. Some compilers have 'em. I've never had to use 'em myself, but my home machine has plenty of MIPs and IoStones. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com