[comp.lang.pascal] Global variables

jc5z+@andrew.cmu.edu (John L. Cusack) (03/25/88)

What is the big deal about not declaring your variables global? At Carnegie
Mellon this is a big deal, but I see that Borland and other programmers have
developed their programs using global variables.  Is it just the different
approach or is Carnegie Mellon trying to prove something by not using global
variables?  What is so wrong with using global variables?

John Cusack
Carnegie Mellon '91

cantrell@arecibo.aero.ORG (JOHN CANTRELL) (03/25/88)

I can't speak for Borland (maybe somebody in netland will), but I can
speak from experience in the DoD software area.  Seen from here, there
are several shortcomings with declaring everything global.  For example:

1. Global variables exist (i.e., they hold space) as long as 
   the program does, locals go away when the procedure is done. 
   Sure, you say, memory is cheap, I can always buy another megabyte.  
   For every megabyte you add, there is some programmer waiting to use it. 
   There are ways to get around this, but why should you, Pascal has
   local variables for this purpose, so why not make use of the 
   facilities of the language.

2. If you have a big project (500,000 lines, 40 programmers), how are
   you going to keep the names straight? Try using i, j and k as loop 
   counters where a subroutine or two is called inside a loop.  If these are
   global, you are guaranteed to have trouble.  And no matter how many loop
   counters you declare globally, I will bet my last dollar that some
   hacker on the project will need 'just one more'.

3. Let's just say that you do declare everything global.  Your names
   may not make much sense to the other programmers on the job, but so
   what, they shouldn't be using your variables anyway.  Then you get
   some new guy on the job finishing up for someone else who left and
   this guy makes the mistake of using one of YOUR variables.  How are
   you going to debug the program when you put everything together later?
   (This is my pet peeve -- I was in testing!)  I tell you how it's done
   now:  You unit test your little piece, then hand it over to the 
   testing organization and get yourself a new job on a new project.  Oh,
   yes, DON'T ever leave a phone number, either, those testing weenies
   will bother the heck out of you with questions when the code is as
   plain as the nose on their face.

Now, just let me get down off the soapbox . . .
So, there really are uses for local declarations.  CMU is probably trying
to get you ready for the great big world out here where all projects are 
NOT one-man jobs.  The best advice: Let them show you the way, but then
reserve judgement until you have worked on a project with 40 other 
programmers -- or better yet, until you have TESTED the work of some 40
programmers.  Then you might get an idea of what they are trying to put
across to you at CMU.

Hope this helps a little.

		-jc

                                John C. Cantrell
                           The Aerospace Corporation
                        2350 East El Segundo Boulevard
                          El Segundo, CA 90245-4691
                             Tel: (213) 336-4333
                          cantrell@arecibo.aero.org
 
*******************************************************************************
*                                                                             *
*     Fill in your own standard disclaimer, but don't hold me responsible!    *
*                                                                             *
*******************************************************************************

------

djones@megatest.UUCP (Dave Jones) (03/26/88)

in article <QWGHNly00Xc=V0s05X@andrew.cmu.edu>, jc5z+@andrew.cmu.edu (John L. Cusack) says:
> 
> What is the big deal about not declaring your variables global? At Carnegie
> Mellon this is a big deal, but I see that Borland and other programmers have
> developed their programs using global variables.  Is it just the different
> approach or is Carnegie Mellon trying to prove something by not using global
> variables?  What is so wrong with using global variables?
> 
> John Cusack
> Carnegie Mellon '91

Good for Carnegie Mellon!  Borland enjoyed phenomenal success.
I lived in Santa Cruz for three years, and I knew several of the
Borland bunch.  They are a remarkable group. I am happy for their them.
But I can't in good faith recommend that anyone emulate the style
of their published code.

I think you may be astonished by the volume of responses your request will
provoke.  I was going to write up my own version of "Death to the
Scurrilous Global Variable!", when I had a better idea.  I'm going to
give you some advice instead. I know I know, free advice is usually worth
what it costs.  But this is a real bargain!  Here it is:

Forget about the responses posted here.  Go to your instructors at Carnegie
Mellon, and ask them to explain.  And do so with an attitude not to prove 
to yourself or them that they are mistaken.   Go to them with a genuine
desire to learn.

Best of luck with your education.  You are very fortunate indeed to
be enrolled at such a prestigious college.


		Dave Jones

		880 Fox Lane
		San Jose, CA.
		95131

		(408) 437-9700 Ext 3227
		UUCP: ucbvax!sun!megatest!djones
		ARPA: megatest!djones@riacs.EDU

hamilton@nmsu.csnet (03/26/88)

	From info-pascal-request%brl-vim.arpa%csnet-relay Thu Mar 24 20:26:00 1988
	Received: from sparta by zia (3.2/NMSU)
		id AA26785; Thu, 24 Mar 88 20:25:58 MST
	Received: from chaco by sparta (3.2/)
		id AA11749; Thu, 24 Mar 88 20:25:47 MST
	Received: by chaco (3.2/NMSU)
		id AA21473; Thu, 24 Mar 88 19:51:02 MST
	Received: from relay.cs.net by RELAY.CS.NET id ai20109; 24 Mar 88 15:31 EST
	Received: from brl-vim.arpa by RELAY.CS.NET id aa27978; 24 Mar 88 15:30 EST
	Received: from BRL-VIM.ARPA by VIM.brl.ARPA id aa02947; 24 Mar 88 14:15 EST
	Received: from brl-adm.arpa by VIM.BRL.ARPA id aa02798; 24 Mar 88 14:04 EST
	Received: from USENET by ADM.BRL.ARPA id aa19178; 24 Mar 88 13:50 EST
	From: "John L. Cusack" <jc5z+%andrew.cmu.edu>
	Newsgroups: comp.lang.pascal
	Subject: Global variables
	Message-Id: <QWGHNly00Xc=V0s05X@andrew.cmu.edu>
	Date: 24 Mar 88 16:16:49 GMT
	To: info-pascal%brl-vim.arpa
	Received: from CSNet-Relay by nmsu; 24 Mar 88 19:10:36-MST (Thu)
	Status: RO
	
	What is the big deal about not declaring your variables global? At Carnegie
	Mellon this is a big deal, but I see that Borland and other programmers have
	developed their programs using global variables.  Is it just the different
	approach or is Carnegie Mellon trying to prove something by not using global
	variables?  What is so wrong with using global variables?
	
	John Cusack
	Carnegie Mellon '91
	

The idea of not using global variables in subprograms (user built 
functions  and procedures) is to make them self-contained.   This 
means  that subprograms will be immune to  any  ill-conceived 
changes  to the main program's global variables.  This  technique 
also enhances the idea of re-usable code.


The  ideas expressed above are my own, and my organization may  or 
may not agree.

     Herb Hamilton
 

dat18@mystefix.liu.se (Dat18) (03/27/88)

> What is the big deal about not declaring your variables global? At Carnegie
> Mellon this is a big deal, but I see that Borland and other programmers have
> developed their programs using global variables.  Is it just the different
> approach or is Carnegie Mellon trying to prove something by not using global
> variables?  What is so wrong with using global variables?

Well, everybody knows that massive use of global variables 
leads to slower code.
That should settle it!

orr@taux01.UUCP (Orr Michael ) (03/29/88)

As one of a team of compiler-writers, including a pascal compiler,
let me note that global variables reduce the compiler's room for
optimization. this is because any time you erite through a pointer,
potentially you may be changing the value of any global var, so the
compiler is prevented from doing a lot of usefull optimizations on
that var. (e.g. allocate the variable in a machine register)
					Michael Orr

firth@sei.cmu.edu (Robert Firth) (03/29/88)

In article <529@taux01.UUCP> orr@taux01.UUCP (Orr Michael ) writes:
>As one of a team of compiler-writers, including a pascal compiler,
>let me note that global variables reduce the compiler's room for
>optimization. this is because any time you erite through a pointer,
>potentially you may be changing the value of any global var...

I don't think that's right.  For example, in Pascal, an explicit
pointer (^Thing) cannot point anywhere except into the heap, ie
at an object created by NEW.  It cannot alias any global variable.

That leaves only VAR parameters as potential aliases.  Even here,
a VAR parameter of one type (VAR p: ThingA) cannot alias a global
variable of any other type (VAR g: ThingB).

The extent to which this matters depends on people's coding style,
but with good Pascal programs (lots of different types) the amount
of possible aliasing is less than 5% (ie for any pointer you know
it cannot alias 95% or more of globals in scope).

shankar@hpclscu.HP.COM (Shankar Unni) (03/30/88)

/ hpclscu:comp.lang.pascal / dat18@mystefix.liu.se (Dat18) /  5:30 pm  Mar 26, 1988 /
> Well, everybody knows that massive use of global variables 
> leads to slower code.
> That should settle it!

Gee, that's rather a blanket statement, isn't it? Most implementations *I*
know of handle local and global references very nicely. It's references that
are both non-local and not global (i.e. a level-n routine accessing variables
at level m where 1 < m < n) that cause the worst code.

Also, (in response to an earlier note), it *is* true that dereferencing a 
general pointer could access anything. But ideally, true Pascal pointers should
only point to the HEAP, which is entirely distinct from locals or globals
or any other address space. Of course, if your implementation allows c-style
pointers (which can point to any item, stack or heap), then of course, a
dereference of such a pointer could write to ANYTHING, INCLUDING YOUR LOCAL
VARIABLES!! Goodbye, optimization!

Thus, knowing the set of items that a pointer can point to can dramatically
improve optimization. It is also helpful if the optimizer can be given hints
about such things, though pseudo-comments or such like.


About the religious argument about global variables: I believe that globals
have their place. They are ugly necessities, not to be indulged in unless the
need is truly present. Their misuse can lead to horrible, unmaintainable
code. Think of the nightmare of keeping track of side-effects! However, I would
not give a second look to a language which did not have adequate facilities 
for declaration of globals and maintaining them in a separate compilation
environment (like that *other* language (NO, NO, NOT FORTRAN!!!!)), because
such a language implementation would be TRULY USELESS.

--scu

orr@taux01.UUCP (Orr Michael ) (03/31/88)

In article <4770@aw.sei.cmu.edu> firth@bd.sei.cmu.edu.UUCP (Robert Firth) writes:
>In article <529@taux01.UUCP> orr@taux01.UUCP (Orr Michael ) writes:
>>As one of a team of compiler-writers, including a pascal compiler,
>>let me note that global variables reduce the compiler's room for
>>optimization. this is because any time you erite through a pointer,
>>potentially you may be changing the value of any global var...
>
>I don't think that's right.  For example, in Pascal, an explicit
>pointer (^Thing) cannot point anywhere except into the heap, ie
>at an object created by NEW.  It cannot alias any global variable.
>
>That leaves only VAR parameters as potential aliases.  Even here,
>a VAR parameter of one type (VAR p: ThingA) cannot alias a global
>variable of any other type (VAR g: ThingB).
>
>The extent to which this matters depends on people's coding style,
>but with good Pascal programs (lots of different types) the amount
>of possible aliasing is less than 5% (ie for any pointer you know
>it cannot alias 95% or more of globals in scope).
	
	You are right, but not entirely right. While it's true that
    in STANDARD pascal a pointer can only point at objects on the heap,
    (i.e. objects you get by NEW), in the CTP compilers, there exists
    an extension allowing you to use 'addr_of(object)'. Moreover, 
    some programmers (and let's not name names ;-) sometimes
    use a variant-record to explicitly manipulate the value of a
    pointer, making it possible to get the pointer to point
    ANYWHERE at all. since this practice is hard to guard against,
    usually you must be pessimistic.
    I would like to make two additional points :
    1. I was talking about global variables in general, not only in
       PASCAL. (in the CTP compiler suite, by the time the optimizer
       sees the code, it has no way of telling that it was originally
       written in PASCAL, as the front-end has transformed it into
       an intermediate representation. Ditto for the code-generator)
    2. There are other good reasons to avoid global variables, all well
       known. (mostly SE reasons). I was only trying to point out a
       relatively unknown disadvantage of global vars. I would guess
       that the reasons for the origianl objections cited, is not the
       one I raised, at least not mainly.


-- 
orr@nsc.NSC.COM		  	      IBM's motto: Machines should work,
{amdhal,decwrl,hplabs,pyramid,sun}!nsc!orr          People should think.
<CTP project, NSTA, Israel (972)52-522259>     Orr's remark: Neither do.
Disclaimer: Opinions, come home. All is forgiven. Papa.

sqkeith@csvax.liv.ac.uk (04/14/88)

In article <4770@aw.sei.cmu.edu>, firth@sei.cmu.edu (Robert Firth) writes:
>
> I don't think that's right.  For example, in Pascal, an explicit
> pointer (^Thing) cannot point anywhere except into the heap, ie
> at an object created by NEW.  It cannot alias any global variable.
> 
> That leaves only VAR parameters as potential aliases.  Even here,
> a VAR parameter of one type (VAR p: ThingA) cannot alias a global
> variable of any other type (VAR g: ThingB).

Ah, but most Pascal compilers encourage filthy habits such as

  var p : ^integer; x : integer;
  begin
    p := @x;
    { or p := address(x); in VAX/VMS pascal }

Admitedly, one doesn't have to use this and decent compilers such as VAX/VMS
Pascal invent an extra layer of type compatibility rules insisting that
x be declared as a [volatile] integer.

		Keith

PS. I can't kick the above habit - I'm a part-time systems programmer!

+-----------------------------------------------------------------------------+
| Keith Halewood, Janet:    sqkeith@csvax.liv.ac.uk                           |
|                 UUCP:     ...!mcvax!ukc!mupsy!liv-cs!sqkeith                |
|                 Internet: sqkeith%csvax.liv.ac.uk@cunyvm.cuny.edu           |
+-----------------------------------------------------------------------------+

piet@ruuinf.UUCP (Piet van Oostrum) (04/18/88)

Posting-Front-End: GNU Emacs 18.47.9 of Mon Mar 21 1988 on ruuinf (hcx/ux)



In article <4770@aw.sei.cmu.edu>, firth@sei.cmu.edu (Robert Firth) writes:
>
> I don't think that's right.  For example, in Pascal, an explicit
> pointer (^Thing) cannot point anywhere except into the heap, ie
> at an object created by NEW.  It cannot alias any global variable.
> 
> That leaves only VAR parameters as potential aliases.  Even here,
> a VAR parameter of one type (VAR p: ThingA) cannot alias a global
> variable of any other type (VAR g: ThingB).

It can if one is a part (field, or array element) of the other.
-- 
Piet van Oostrum, Dept of Computer Science, University of Utrecht
Budapestlaan 6, P.O. Box 80.012, 3508 TA Utrecht, The Netherlands
Telephone: +31-30-531806              UUCP: ...!mcvax!ruuinf!piet