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