Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!umcp-cs!chris From: chris@umcp-cs.UUCP (Chris Torek) Newsgroups: net.lang.c Subject: Re: Proposal to add modules to C Message-ID: <5751@umcp-cs.UUCP> Date: Tue, 14-May-85 22:01:53 EDT Article-I.D.: umcp-cs.5751 Posted: Tue May 14 22:01:53 1985 Date-Received: Thu, 16-May-85 20:28:36 EDT References: <224@sdcc13.UUCP> <5400006@prism.UUCP> Organization: U of Maryland, Computer Science Dept., College Park, MD Lines: 43 It seems to me that the main (if not only) reason to avoid using global variables (as opposed to ``module-level'' variables, i.e., accessible to foo.c and bar.c but not baz.c) is to avoid name collisions. If the variable makes sense as a statically-allocated unit, why would you care whether baz.c can get at it, unless you want to ensure that no accidental changes or references are made? [I will mention functions later.] Anyway, assuming that I'm not already way off base, this can be done quite easily in C as it stands right now, by using long names (let's not start *that* again: I only need long internals for this argument, and the current ANSI draft has 31 character internal names) and structures. For example, if files foo1 and foo2 are to share access to a data structure, you might create a corresponding foo.h file: struct foodata { /* private globals for foo */ int fd_int; double fd_fp; /* and more */ }; extern struct foodata foodata; /* declared in fooglob.c */ /* Now we hide the fact that they are really in a struct */ #define foo_int foodata.fd_int #define foo_fp foodata.fd_fp Within foo1 and foo2, these variables appear to be globals. To anyone who does not include foo.h, there is only one name to worry about (and it need not make much sense; indeed you can hide the ugly 6-character externals this way---#define's are internal names, and therefore have at least 31 significant characters). This admittedly leaves function names out in the cold.... I'd suggest using function pointers inside foodata, and initialization routines, but someone would gripe about run time. (Personally, I'll just use my long identifier names.) Well, if you want more, try Mesa. It's got more modules (and more strict type checking) than any Unix hacker would know what to do with.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland