C common practice. (was: low level optimization)

[Joe English]

jlg at cochiti.lanl.gov (Jim Giles) writes:
>In article <15904 at smoke.brl.mil>, gwyn at smoke.brl.mil (Doug Gwyn) writes:
>|> This is the second "common C programming practice" you have raised
>|> in this thread that is in fact NOT a common practice among skilled
>|> C programmers.  If your argument is that C requires a certain
>|> degree of expertise to use WELL, then you're wasting our time,
>|> since that has never been in question.
>
>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, and if you had ever read
any of the source code posted to the net by various comp.lang.c
luminaries you'd see that *they* don't write C programs that way either.  

(The vast majority of all the Fortran code I've seen, on the other
hand, *is* written that way, but that's OK since Fortran can be
optimized so much better than C that interprocedural optimizations
aren't necessary.)
 
>The
>reason is two fold: 1) common implementations of C will load _all_
>procedures that were in the same source file even if only _one_ was
>called - so you pay a penalty in loading dead code if you don't 
>break your code into separate files; 2) UNIX code maintenence tools
>(like make) are designed to operate on the _file_ level - which makes
>one procedure per file a natural maintenence decision.

That makes putting one *module* or *group of related functions*
in one file a natural maintenance decision.  A lot of C programs
*are* written this way.

Jim will probably ignore this posting.

--Joe English

  jeenglis at alcor.usc.edu