Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!psuvax1!hsdndev!cmcl2!lanl!cochiti.lanl.gov!jlg
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.c
Subject: Re: C common practice. (was: low level optimization)
Message-ID: <22649@lanl.gov>
Date: 25 Apr 91 23:02:53 GMT
References: <22354@lanl.gov> <16815@chaph.usc.edu> <1991Apr24.050556.16405@athena.mit.edu>
Sender: news@lanl.gov
Organization: Los Alamos National Laboratory
Lines: 26

In article <1991Apr24.050556.16405@athena.mit.edu>, scs@adam.mit.edu (Steve Summit) writes:
|> [... bunch of stuff about trade-offs of separate files for each 
|>      procedure - most of which I agree with ...]
|>
|> 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.

One of the assumptions (which is still valid most places) is that
no interprocedural analysis is done - even _within_ a file, even 
though the language permits such optimizations.  The result is that
there really is a tendency to maintain C code as numerous separate
files.  Even closely related codes tend to be fragmented this way.
For example: the X11R4 xterm program is maintained as 16 separate
source files even though it is _one_ utility and I know of no other
program which shares any code with these 16 files.  There is not
really any reason for this code to be maintained in more than _one_
file.

I don't maintain that keeping code in separate file is necessarily
bad or good.  But to pretend that it is not common practice is to 
ignore reality.  This common practice may in (the near) future result 
in less efficient code because of missed optimization.

J. Giles