Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!think.com!snorkelwacker.mit.edu!ai-lab!life!tmb From: tmb@ai.mit.edu (Thomas M. Breuel) Newsgroups: comp.lang.c Subject: Re: C common practice. (what it really is) Message-ID: Date: 29 Apr 91 05:49:17 GMT References: <1991Apr27.024634.586@convex.com> Sender: news@ai.mit.edu Organization: MIT Artificial Intelligence Lab Lines: 18 In-reply-to: grogers@convex.com's message of 27 Apr 91 02:46:34 GMT In article <1991Apr27.024634.586@convex.com> grogers@convex.com (Geoffrey Rogers) writes: In article tmb@ai.mit.edu (Thomas M. Breuel) writes: >In terms of compilation speed and code optimization, having only one >function per source file is about the worst you can possibly do: you >pay the cost for parsing lots of include files for each function you >compile, and, with most compilers, you inhibit all global optimization. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Huh???? What do you mean by global optimization? Most texts on optimization consider global optimization to be between basic blocks within a procdure. Having one function per source file does not inhibit this. Everything else that you said is true/good common sense. If you don't like the term "global" (which is often used in this sense), call it "interprocedural". For example, GNU C performs inlining at compile time, not link time, and this is inhibited by putting each function into a separate file. Likewise, a compiler can only determine that a function is side-effect free if the source code to that function is available at compile time.