Are globals really THAT bad?

Quote:

Original post by nsto119 Most people around say that you should avoid globals like the plague... why? Every single large piece of software I've ever worked with has used globals extensively. Often, there IS data that you want to have global access to. Not to mention, it seems like just using a global variable is often much, much easier than trying to hide it but at the same time allow pieces of code that need to, access it. I dunno, it's just a thought I had a while ago.

class MyClass{...};// All over your cpp...void MyClass::oneMethod(){   ...   g_app.log("Here's some useful information");   ...}

class ILog{public:   virtual void log(const std::string& p_text) = 0;};class MyClass{public:   MyClass(ILog& p_log);...private:   ILog& log_;};// in MyClass.cpp:void MyClass::oneMethod(){   ...   log_.log("Here's some useful information"); // No known implementation details of how it's logging = a win   ...}

MyClass myClass(screenLogger_);

MyClass myClass(remoteLogger_);

MyClass myClass(debugWindowLogger_);

(As a side note, it's important to know that code reuse is not restricted to reusing a piece of code from another project: it's perfectly possible, and even interesting efficiency-wise, to reuse code within the same project).

Quote:

Original post by Yann L I personally find this general global-o-phobia a little exagerrated at times. Sure, a global ridden program is a pain to maintain. But ironically, a few well selected central globals can make code much easier to maintain, and also make it faster. In larger projects, we usually have a central class that holds instances to the main subsystems of the application (eg. GUI control, plugin management, renderer, configuration, error handling, etc). Most of these instances can be seen as global system services, that are (and should be) available to everybody. Now, passing around pointers to these objects is just dumb, and a maintenance nightmare on its own. We habe instead opted to create a single global with the instance of the applications subsystem tree. That instance is explicitely created on startup and destroyed at shutdown. During operation, everybody can access the services by using the global pointer. This has proven to work very well, to be highly scalable, and easy to maintain.

Quote:

Original post by Rydinare Anyway, the above is my usual knocks against it. That being said, I can agree that, in certain instances, the dependency of having to pass around a "global" type of object such a logger everywhere can become a bit of annoyance. Is there a compromise that would work around both concerns?

Quote:

Original post by Rydinare Take the above advice with the caveat, as long as the entire app requires the same behavior.

Quote:

Original post by Rydinare we usually have barely a sense of what current needs are

Quote:

Original post by Yann L Quote: Original post by Rydinare Take the above advice with the caveat, as long as the entire app requires the same behavior. Define 'require the same behaviour'. A certain subsystem provides a certain known service with a certain, known, and well documented interface. Maintaining this framework is extremely important, especially with an application that relies heavily on a plugin architecture. There is no difference here between offering this service via a global request mechanism, or via handing around pointers or references to it.

Quote:

Original post by Yann L Quote: Original post by Rydinare we usually have barely a sense of what current needs are In that case, you have a case of bad project planning.

Quote:

Some of these example are pretty damn funny. Just write your code any way you see fit. People need to remember that most people here with these sorts of questions are not writing with a massive team. They're "Lone Codeman." Don't get dogged down by details like multi-threading and distributed environments until you're ready.

Quote:

Original post by frob But for most people on the board, their goal is to write a game, not to architect an all-encompassing system that will survive decades of scrutiny. The most important task is to get something done.

Quote:

Every single large piece of software I've ever worked with has used globals extensively

Quote:

Even when they ARE writing on a team, decisions about threading and environments will be made by your leads and the senior engineers who have enough experience to know the answers.

Quote:

Original post by nsto119 Most people around say that you should avoid globals like the plague... why?

Quote:

Original post by taby Yes, global variables are bad. They are a cheap and lazy way to avoid having to pass extra parameters around from function to function. I won't name names, but a very popular open source secure FTP package uses global variables extensively. The author attempted to "clean up" properly when the functions return, but the attempt utterly failed (did they not test this stuff at all?). If you want to integrate their source code into your own, the only way I could do it successfully was to move it into its own DLL, then manually link into it at runtime, run the function one needs, then unlink the DLL. This has to be done every time the function is called. VERY DISGUSTING. If I had known it would have been this way, it probably would have taken me less time to write my own package for all of the time I wasted trying to fix the broken code. Don't use global variables. I'm always leary of suggesting the use of singleton classes in C++, but at least they are one huge step better than global variables.