Proposal to add modules to C with a

matt at prism.UUCP matt at prism.UUCP
Sat May 11 03:21:00 AEST 1985

/**** prism:net.lang.c / reed!alexis /  3:00 am  May  5, 1985 ****/

  What about letting functions in DIFFERENT files share hidden data?
That is, for me, the major stumbling block with the current semantics of
external statics.  The 'block' approach does not help any. (Unless you
can leave a block open at the end of the file!! :-)).  

	  alexis @ reed
/* ---------- */

I quite agree.  I find that the biggest obstacle to true modularity in C
programming is that functions sharing external static data must exist in the
same source file.  This is painful if, like me, you want to avoid global
variables but also want to organize your source files in a rational way.
(E.g., all machine-dependent code in one file, even if the code shares
external static data with other functions.)  

It is doubly painful if your linker cannot extract only required functions
from an individual object file.  Each time you link ANY function that uses
the shared static information, you are forced to carry along the deadweight
of all the other functions in the source file.  This may not matter on a
VAX, but you can certainly feel it on an 8088 wit a 64K address space!

Unfortunately, neither C nor C++ provides any facility for multiple-source
modules.  In fact, it isn't even clear what the syntax for such modules
should look like, or where it should be specfied.  (Is there some way for
a compiler to deal with this, or should it be specified for the linker, like
some overlay structures for MS-DOS machines are?)

What are people's thoughts about modules composed of multiple source files?
Anyone have a proposed syntax for implementing them?  (ANSI people, are you

 Matt Landau            {cca, ihnp4, inmet, mit-eddie, wjh12}...
 Mirror Systems, Inc.                                   ...mirror!prism!matt

More information about the Comp.lang.c mailing list