   global variables or alternatives?
  I keep hearing that global variables are bad. Then someone says they arent that bad in some situations. What situations? I personally dont like them because they dont seem ''neat'' or professional. But is there ever a case where you cant get around using them? Im currently making a program that is going to be aware of keyboard input. So i made a class called Keyboard that will be a representation of which keys are being pressed on the keyboard at all times. Im going to need this Keyboard class in several different files and classes. My first thought was to make a global instance of the Keyboard class, and then use that from all the files. Is there a better way to do what I want to do, and avoid global variables? If not, what is the best way to use global variables? Should I put this line:extern Keyboard kbrd;in a global.h file, and include that file in all the other files that need the keyboard class? or what?thanks 
  One thing I hate about global variables (and especially objects) is that there is no sure way of telling in which order they get instanciated.I prefer to implement singletons (objects with a single instance in the whole game) like that // HEADER///////////////////////////class CKeyboard{public:static CKeyboard* Instance(void);static void ShutdownInstance(void);virtual void Update();virtual bool KeyPressed(int iKeyCode);    private:    CKeyboard(void);    ~CKeybopard(void);    static CKeyboard* g_pKeyboardInstance;};// CPP///////////////////////////CKeyboard* CKeyboard::g_pKeyboardInstance=NULL;CKeyboard* CKeyboard::Instance(void){    if (!g_pKeyboardInstance)   g_pKeyboardInstance = new CKeyboard();    return g_pKeyboardInstance;}void ShutdownInstance(void){    if (g_pKeyboardInstance)   deelte g_pKeyboardInstance;    g_pKeyboardInstance = NULL;}void CKeyboard::Update(){............}bool CKeyboard::KeyPressed(int iKeyCode){............}    CKeyboard::CKeyboard(long hWindowHandle){...............}CKeybopard::~CKeybopard(void){............}you call shutdown instance when the progam shuts down. you initialise all singletons at the program initialisation. Obviously, you need to initialise singletons in the right order. The memory manager, the windows interface, the renderer, the audio device, the keyboard device....That way, you know the order of initialisation, and when you shutdown, you can cleanly shutdown the game without memory fragmentation (if you are so incline).;  what i would do is make a global system code. include all your extra variables, functions into this one class. make it global, that way you don''t have to keep sending in the bugger, the only thing you would have to do is maybe send in a event call or somethin. that''s what im doin in my game.   Higher Forces;  hogosha, could you explain that a little more clearly? im not really sure what you meant?oliii, that sounds like a neat idea. then how do you declare the global singleton class and such? with an extern statement at the top of each file or what?thanks! ;  As long as you stay with the base types for global variables and pointers when creating non base types(ie your classes), there is nothing to worry about. I''ve seen lots of commercial code and I don''t think I ever seen one that doesn''t use global variables, pointers, except from very small programs.. ;  Globals indeed lead to ugly code. Or they''re a means for implementing bad designs."Im going to need this Keyboard class in several different files and classes."No, you''re not going to need it in several random places. Try to handle input in a single place, or two at most. Not only will you make the design clearer, you could for example add AI which only simulates keyboard presses and thus plays "fairly" (assuming you''re making a game).Whenever you notice that "hey I need to use this object in 10 totally different places" and your immediate thought is that a global makes it simple, the reality is that a global is in fact a hack to implement a bad design. A better design would save you from the need of globals entirely.Singletons aren''t really a better solution. They''re the same hack with a new name and a few good properties. They''re better than globals, but still inherently as ugly. ;quote:Original post by Anonymous Poster  Globals indeed lead to ugly code. Saying something is ugly is an opinion, so i dont think you can really say they lead to ugly code in such certain terms.  I think globals have there uses, although over using them can be confusing.   ;quote:Original post by quant  Saying something is ugly is an opinion, so i dont think you can really say they lead to ugly code in such certain terms. If you prove a simple math theorem in 100 pages, it''s ugly. If you prove it in 5 lines, it''s most likely very beautiful. I don''t think anyone can disagree while keeping a straight face. We''re not talking about the beauty of a landscape, or a painting here. Beauty in code is much more well defined - by it''s length (the amount of symbols), how easy it is to extend and how easy it is to understand the control flow. And a bunch of other properties.;quote:Original post by Anonymous Poster  If you prove a simple math theorem in 100 pages, it''s ugly. If you prove it in 5 lines, it''s most likely very beautiful. I don''t think anyone can disagree while keeping a straight face. We''re not talking about the beauty of a landscape, or a painting here. Beauty in code is much more well defined - by it''s length (the amount of symbols), how easy it is to extend and how easy it is to understand the control flow. And a bunch of other properties.Sounds like an opinion to me (because it is an opinion).  And whats a 100 page math theorem got to do with using a global variable? using globals can sometimes make your code shorter without any loss in the ''flow'' of your code, and so why not use them? your comparisons seem somewhat amusing.;quote:Original post by quant  And whats a 100 page math theorem got to do with using a global variable?->quote:your comparisons seem somewhat amusing.No wonder. 