   OO C++ Question
  Ok, so I'm trying to keep my (fledgling) engine as modular as I can, so I have different classes for different modules.  For example I have a Terrain class that handles all aspects of the terrain, loading the heightmap, driving an array of cPatch objects, etc.  Also I have a debug class, which displays messages to the screen.  Each class has an object that is declared globally in my main.cpp file, making it global to anything in main.  My question is what is the best way to be able to call debug.print("debug string") say inside my Terrain.LoadHMP function?  Currently I know I can pass a pointer to debug into my Terrain.LoadHMP function, and call debug_ptr->print("") or I can also store a pointer to my debug class object as one of Terrain's member variables and always have access to it.  Since I will have many many modules (objects) that will interact and call on each other, this might get confusing.  Is one of these the best option, or is there something really cool I don't even know about?   
  if you want to make your engine modular, you want to avoid global variables as much as possiblemodularity = encapsulation = !(global variables)(geek slang here)I think it's okay for things such as a debugging output object, since it's not really part of the domainbut for a terrain (for example), I wouldn't make it global...I'd have each terrain represented as a single instance, and each terrain knows how to load itself...it opens the door to polymorphism in the futureso instead of having Terrain.loadHTMP(filename)I'd rather haveTerrain* terrain = new Terrain();terrain->loadHTMP(filename);and if you need that terrain somewhere else you just pass the pointer around to the methods that need it...that's a more solid encapsulation and can avoid confusion if your engine gets big   ;  Are you sure you aren't trying to solve the wrong problem?Plus. Is your debugger enabled in compile-time or run-time?   ;  In the source file you can include the whole headers.Using forward declarations instead of that is only required in the header files sometimes.Btw. you might want to define a Logfile class.If all modules use the same then give the Debug class a pointer to one Logfile object as a static member.You can then use:Logfile* pLog = Debugger::get_pLog();and access the same file from any source file.With that approach it will also be easier to give the modules their own Logfiles later if you should need that in the future.   ;  SlashOwnsU:Thanks, your post was helpful, pretty much I should be using pointers and pass them wherever they're needed.  My only questions are about where they should be 1) declared, and 2) actually instantiated with the 'new' operator. Currently I declare them in my WinMain function, and invoke their constructors in my Init function.Cheery:I'm not sure what you mean, I take it you feel I'm going about this all wrong and I welcome your suggestions.  Also my debug object is enabled all the time, but its visibility can be toggled at run time via the 'D' key.  I feel I should explain a little more about this.  It has as a member variable a fixed size array of 8 char pointers.  I ->add() strings to the list, and when the list reaches its capacity, the oldest one is bumped out.  It will show the latest string added, and also the 7 previous ones (in case some function fires out 3 or 4 debug messages in rapid succession)It will eventually either become a compile time option (#defining DEBUG as 0 or 1 is the way to go about this i'm assuming?) or it will turn into part of the HUD or something like that.EDIT:Clueless:Sorry, you snuck a post in there as I was writing a reply.  Anyway, as you can see above, my debugger is not quite that robust to generate log files just yet, but I will keep your comment in mind should the need arise.   ;  There are two general ways that I see to handle things like this. The first is that you may want to look in to the Singleton design pattern (google it). Essentially, you'd be able to do:DebugLog::Instance()->Print("my string here\n")From anywhere as long as you include the debug class header file. Note that Singleton's are really little more than an OO version of a global variable, but they do tend to be a little more readable.The other way is to use a single central singleton that holds pointers to various systems you need to access from a variety of places. So, you may have your application class and then do something like:Application::Instance()->GetDebugLog()->Print("my string here\n")Note that there are certain cases where things like Singleton's and global variables tend to work well -- a debug log for instance -- while in general you should try to avoid such things.   