Xref: utzoo comp.software-eng:2634 comp.misc:7609
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!coherent!dplatt
From: dplatt@coherent.com (Dave Platt)
Newsgroups: comp.software-eng,comp.misc
Subject: Re: Coding standards (was Re: Programmer productivity)
Message-ID: <41413@improper.coherent.com>
Date: 7 Dec 89 19:19:00 GMT
References: <1989Dec6.154103.2078@twwells.com> <14850@well.UUCP>
Reply-To: dplatt@coherent.com (Dave Platt)
Followup-To: comp.software-eng
Organization: Coherent Thought Inc., Palo Alto CA
Lines: 46

In article <14850@well.UUCP> Jef Poskanzer <jef@well.sf.ca.us> writes:
> Anyway, the last time this discussion came up, I posted a transcript of
> a session with the VMS FORTRAN compiler and the VMS linker.  They have
> no problem at all separating a single source file into one object
> module per routine.  The reaction then was, "Oh sure, FORTRAN can do
> that, but we were discussing *real* languages."  "Real" languages
> meaning C, of course.

The Honeywell CP-6 object language and linker supports this sort of
feature, as well.  Object-language records are stored in a "keyed file"
(a B-tree file, in effect);  it's possible to store many object-language
packages in a single keyed file with no interference.

The linker brings in the necessary object-language modules, by searching
the "external functions defined" record for each module, and loading only
those modules which define a function that's actually needed.

All external (global) data variables are, by definition, contained
within an object module.. and hence within a function.  This isn't
entirely consistent with the C model, which defines globals as being
those variables which lie _outside_ of any function.

One way in which a savvy C compiler could resolve this, would be to bundle
all of the global variables into a dummy module.  Each real module
(function) in the source-file would access the global variables as if
they had been declared "extern".  If the linker fetched a function-module
from the object file, it would "see" that the module was accessing some
extern variables, would search the "external variables defined" records
in the object file, and link in the dummy module (which defined the
globals) as a result.

There's a cost to this approach, though.  It requires that all global
variables be accessed as "externs", even if they were defined in the
same source-file as they're being used.  This makes it difficult to
have "static" variables of file scope... because the very use of the
"static" keyword requires that the variables' names not be exported
(for reasons of data-hiding, name-space pollution, etc.)

An effective C compiler can get around this problem by hashing the names
of the static variables into some horrible string that's guaranteed not
to collide with any other name.
-- 
Dave Platt                                             VOICE: (415) 493-8805
  UUCP: ...!{ames,apple,uunet}!coherent!dplatt   DOMAIN: dplatt@coherent.com
  INTERNET:       coherent!dplatt@ames.arpa,  ...@uunet.uu.net 
  USNAIL: Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303