From: fmatthew5876@googlemail.com   
      
   { Please limit your text to fit within 80 columns, preferably around 70,   
     so that readers don't have to scroll horizontally to read each line.   
      
     Please don't double-space the quoted material.   
      
     This article has been reformatted manually by the moderator. -mod }   
      
   > One function parameter would be enough, for a "system" object that   
   > holds references to those three other sub systems. You may also find   
      
   That might save us a little typing and registers for parameter   
   passing but it doesn't solve the general book keeping mess of passing   
   these global objects around all over the place.   
      
   It also adds a nasty coupling relationship. Now everything needs to know   
   about this "system" object and every time it changes to support a new   
   global object that one small subset of the system *might* want to   
   use, virtually everything needs to be recompiled.   
      
   This also makes it much harder to build a modular library. Going back to the   
   example of games. If one part of my code is doing rendering and physics, it   
   doesn't need to have access to a pointer to the audio subsystem. In fact I may   
   want to drop in an entirely different audio library. With a static "system"   
   pointer object as described this becomes very difficult if not impossible.   
   Dynamic polymorphism is not the answer to this problem either. Forcing everyone   
   into your narrowly defined class interface also inhibits modularity.   
      
   > you can store a reference to the system object in each game object, or   
   > some other place already accessible, so most of the time you don't   
   > need to pass it around at all.   
      
   Storing a reference to a global object in every local object seems like   
   a non-starter to me. Not only is it wasteful of memory, it also   
   complicates things as now we have an unknown number of references to a   
   global object hanging around. Plenty of opportunity for hard to track   
   danging resource leaks there.   
   It also means every time you construct these objects you still need to   
   do book keeping by passing in references to the global objects they will   
   need to use.   
      
   You could do some kind of reference counting scheme but this adds even   
   more overhead and complexity for what appears to already be of little   
   value. Reference counting also adds an element of unpredictability to   
   object destruction, which can be important for performance critical   
   applications.   
      
   If your target application is well defined (not overly generic), certain   
   things might make sense to be globals. A good example is stdin. We don't   
   need to make instances of stdin and pass them around to different parts   
   of the code so that they can print to the console just *in case* there   
   ever might be more than one standard input stream. We don't create some   
   clumsy singleton class where people have to obtain an instance using some   
   arcane syntax and then call methods on it, with hacks around the language   
   (local static variables) to ensure that the compiler makes it impossible   
   for them to do something stupid like creating another instance.   
      
   You just call printf or cout and you're done. Its the cleanest,   
   simplest, most efficient, and most direct way to interact with the   
   system. To me, singleton patterns just add complexity. They appear to be   
   nothing more than glorified global variables trying to pretend to be   
   sophisticated object oriented design patterns.   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)