C common practice. (was: low level optimization)

[Jim Giles]

In article <15904 at smoke.brl.mil>, gwyn at smoke.brl.mil (Doug Gwyn) writes:
|> In article <21964 at lanl.gov> jlg at cochiti.lanl.gov (Jim Giles) writes:
|> >... the common practice of C programmers putting each function in its own
|> >separate file makes the mistake double easy to fall into.  ...
|> 
|> 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.  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.

I _don't_ say that dividing code into separate files is "good"
style.  The advantage that interprocedure analysis _can_ be
carried out _within_ a file is a strong incentive to combine
routines into the same file. Further, "static" globals (that is
"private" variables) are an important tool for modularizing
code and verifying correctness.  Against that is the overhead
of loading a whole "file" when you call only one procedure.
It is a trade-off only the end user can intelligently make.

If the loaders on UNIX machines were modified to load only those
procedures which were actually called, then I would not hesitate
to recommend combining procedures into common files whenever
possible.

J. Giles