C common practice. (was: low level optimization)

[Steve Summit]

In article <16815 at chaph.usc.edu> jeenglis at alcor.usc.edu (Joe English) writes:
>jlg at cochiti.lanl.gov (Jim Giles) writes:
>>On the contrary.  Putting each C procedure into a separate file _is_
>>common practice.  It is promoted as "good" style by C gurus.  Skilled
>>C programmers recommend it - they don't avoid it or condemn it.  
>
>I've never heard that style promoted by any C gurus.  I've never seen
>that style *used* by any C gurus.  I don't write C programs that way,
>no one I know writes C programs that way...

Like (nearly) everything else, this issue is not cut-and-dried,
and arguments must be evaluated, on their merits, with respect to
the problem at hand.

When writing a large program, closely related functions can well
be placed in the same source file, both for logical cohesiveness
and to allow information hiding via file-scope static variables.

When writing a general-purpose library, however, it is a very
good idea to use a very fine, one-subroutine-or-nearly-so-per-
source-file granularity, since a given application being linked
against the library will usually use only a fraction of its
routines.  (To be sure, a "smarter" linker could help here, by
doing only partial loads of object files, but that's never
something I've thought a linker was "supposed" to do -- loading
only what's needed is exactly what libraries are for, at least in
the C/Unix "world" I'm used to.)  It's true that fine granularity
can work against enforced data hiding, but naming conventions (to
avoid name collisions, even if the "private" data isn't truly
hidden) work well in practice.

(If you are writing a general-purpose library which contains any
extensions in the form of newer routines which users might not
know about, putting each one in its own file is mandatory, so
that it cannot get pulled in when not needed and cause a name
clash.  For example, ANSI C does not prohibit implementors from
placing nonstandard routines in the C run-time library, as long
as their presence there cannot hurt oblivious programmers who
happen to have their own routines with the same names.)

In the (interminable) debate leading up to this side thread, I
suspect that Jim Giles has been thinking mainly or exclusively
about writing libraries (which furthermore will be used without
source available), so the difficulty of achieving good intermodule
optimization looms large for him.  For people who are thinking
instead about more standalone applications programs, or are not
focusing on one aspect of one problem at all, the issue is less
interesting and/or less exciting and/or more amenable to solution.

The one thing I was going to contribute to the "low level
optimization" thread was to suggest that people watch their
underlying assumptions, hidden agendas, and foregone conclusions --
if those don't match, you can argue forever.

                                            Steve Summit
                                            scs at adam.mit.edu