From: Mungo Henning Newsgroups: comp.os.msdos.djgpp Subject: Re: Global variables and structs? Date: Thu, 17 Feb 2000 17:51:26 +0000 Organization: itacs Lines: 81 Message-ID: <38AC351D.6FF106D3@bigfoot.com> References: NNTP-Posting-Host: kite15.itacs.strath.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com "William J. Urban II" wrote: > Hello all, > Well I am in a C++ class and also teaching myself some simple 2d game > writing with allegro. Now, in class we learned about Global variables and > how we should use them sparingly. My question is why? In a large program there can be a significant stack of functions which call each other. For example, function A calls function B which calls function C and so on (say) down to function Z. Once the program has been established, it becomes obvious that a new bit of information which is needed in function Z is actually available in function A. So how do we get the data from A to Z? Arguably, the *best* solution is to modify functions B through Z to accept a new parameter. This gives a clean interface. But, wait a minute, functions B through Z are also called from many other places, so they too will have to donate the extra argument or the compiler will complain. So, since it is Friday afternoon when you are doing this change, the quick-fix is to copy the data into a global variable (in function A) then pick it up in function Z. Everything works fine and dandy: you don't understand the hassle that everyone talks about with global variables. Some time later you find out that function M wants to call function N twice, the first time as normal and the second time with a different piece of information which is stored in the global. So function M ends up creating a temporary of the same type as the global, copying the global there, overwriting the global, calling function N then copying the temporary back into the global. Phew, gotta stack up the global, change it then proceed then undo the damage. And then you find that under some circumstances a lower-down function does (say) a longjmp and by-passes the undoing stage... And then the mire of globals becomes visible. Trust your teacher: in a big project globals can be deadly! Unless rigorously managed, they can turn and gobble you up! :-) I teach my delegates a few rules regarding globals: 1) don't create any 2) If you have to, tomorrow or next week is fine 3) Put your name and the date beside the global (in a comment) so that the guilty party can be identified later and fired. 4) Use "static" as a default until the global's scope widens 5) Ensure that each global has a loooooong unambiguous name (no globals called "i", "j" or "k" else you gotta check all "for" loops) HTH Mungo P.S> I'm ignoring the "X-windows" idea of a structure pointer and a bit mask flag to help when adding new information. -- Mungo Henning - it's a daft name but it goes with the face... mungoh AT bigfoot DOT com http://www.itacs.strath.ac.uk/ I speak for me, not my employer.