Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ucla-cs!zen!ucbvax!amdcad!tim
From: tim@amdcad.AMD.COM (Tim Olson)
Newsgroups: comp.lang.c
Subject: Re: portability and standards
Message-ID: <17365@amdcad.AMD.COM>
Date: Fri, 3-Jul-87 14:47:32 EDT
Article-I.D.: amdcad.17365
Posted: Fri Jul  3 14:47:32 1987
Date-Received: Sat, 4-Jul-87 14:16:15 EDT
References: <2290@calmasd.GE.COM> <4715@columbia.UUCP> <107@snark.UUCP>
Reply-To: tim@amdcad.UUCP (Tim Olson)
Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca.
Lines: 27

In article <107@snark.UUCP> eric@snark.UUCP (Eric S. Raymond) writes:
+-----
| I submit, though, that this whole discussion rests on a false premise --
| that it is somehow a Good Thing to have a separate globals module with no code.
| Every time I've seen such a module it has been evidence for poor data
| design in the program. Globals are bad style, the data design equivalent
| of goto statements.
| 
| I recommend the elimination of globals, and the more general habit of thinking
| in ADTs, to C programmers everywhere. The grief you save may be your own.
+-----
This is all well and good when the program *can* be partitioned into
modules, each with their own data structures and procedures which
operate on them, but there are many cases where this doesn't work.  For
example, we use this technique wherever possible when we wrote the
Am29000 processor simulator, but there are still *many* signals (global
variables) which are visible to all modules, and don't have a logical
owner: the clock, various pipeline hold conditions, global control
registers, etc.  In this case, the most logical place to put them was a
global.h file which was included in every .c file which required them. 
The #ifdef GLOBAL technique was used to prevent multiple copies (.c and
.h) of the global variables.

	-- Tim Olson
	Advanced Micro Devices
	(tim@amdcad.amd.com)