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