Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!ukma!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: <22636@lanl.gov>
Date: 25 Apr 91 20:44:27 GMT
References: <21964@lanl.gov> <15904@smoke.brl.mil> <22354@lanl.gov> <16815@chaph.usc.edu>
Sender: news@lanl.gov
Organization: Los Alamos National Laboratory
Lines: 35

In article <16815@chaph.usc.edu>, jeenglis@alcor.usc.edu (Joe English) writes:
|> jlg@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. 
|> [...]
|> (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.)

I've never seen Fortran fragmented into one file per routine except
for those very few Fortran programs written by ex-C programmers.
Many half-million line Fortran programs I've seen were maintained
in just a single file - all thousand-odd subroutines.  I don't agree
maintaining code quite so monolithically, but it is _cartainly_ not
fragmented as you are claiming.

In C, on the other hand, fragmenting seems to be to order of the day.
For example, all the UNIX utilities on Cray UNICOS are maintained
as huge numbers of separate source files.  The X11R4 version of
xterm is distributed as 16 separate source files (even though it's
a fairly small program that does most of its work by calling widgets).
Speaking of which, the widgets are distributed as over a hundred
little .c files - mostly one per procedure.

One file per procedure appears to be standard C practice to me.

|> [...]
|> Jim will probably ignore this posting.

Dream on.

J. Giles