C common practice. (what it really is)

Thomas M. Breuel tmb at ai.mit.edu
Mon Apr 29 15:49:17 AEST 1991


In article <1991Apr27.024634.586 at convex.com> grogers at convex.com (Geoffrey Rogers) writes:
   In article <TMB.91Apr26145719 at volterra.ai.mit.edu> tmb at 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.



More information about the Comp.lang.c mailing list