There's only a few reasons to use a global:
1) You're lazy and can't figure out a better design yet.
2) Constants.
3) You're in a situation where you absolutely have no alternative but to use a global. Which is exactly almost never.
You currently fall under case #1. Laziness is ok sometimes if you don't care about people looking over your shoulder and chastising your lack of perfection. Just roll with it. You're not going to be holding this code up on a pedestal 2 years from now, marveling at it's perfection, so just go with your gut and learn from it later.
That is an amazingly elitist statement.
Many things are global for good reason.
There is a global memory allocator, provided by the system. You can provide more narrowly-scoped versions, but there is a global one that is created for you by the system. Would you remove it from the language? How would you replace it?
There are global IO streams, provided by the system. You do not need to use them, but they are present for all takers. There is a globally used locale object. Would you remove them, and require every program that performs even the most simple I/O to construct locale objects, and have every stream get imbuded with this custom object?
Calls to kernel control, hardware control, iocontrol, and other system settings are global settings. Any thing with scope bigger than just your program is effectively global to your program. Good luck removing them.
Many programs will create a general purpose logger and create a global instance for general use. Many programs will create per-frame performance data and update information, and make it available globally for general use to any system that needs to know. Many programs will have a global object with pointers to various systems and managers since those systems truly need to be known and used across the program.
Many times a class will have need of a general purpose object that specifies behavior that can be shared but can also be replaced if necessary. Such a shared object can often be best implemented as a global object.
Yes, when used incorrectly global objects will increase code complexity and module interdependence. Don't do that.
However, used properly, global variables can dramatically reduce code complexity. That's when you use them.
A hammer is a tool that when used incorrectly can cause serious problems. But used correctly it is a great tool.
Fire is a tool that when used incorrectly can cause serious problems. But used correctly it is a great tool.
Surgery is a tool that when used incorrectly can cause serious problems. But used correctly it is a great tool.
Dynamite is a tool that when used incorrectly can cause serious problems. But used correctly it is a great tool.
Similarly, so it is with global objects.
Yes, there are many reasons to not use globals. Globals lose locality controls, and they can have issues with access control and constraint checking (although they don't have to if designed properly). Globals can have concurrency issues, and they can introduce some issues for testing. Used improperly they suffer from side effects. Indiscriminate access to a global variable can seem to show very odd functionality, but this is always true: if you start mucking around with the stdout stream and changing its properties you can expect problems from anyone using the stdout. If you start mucking around with the global locale you can expect all your streams changed based on the locale settings. The problem isn't the existence of the global object, the problem is the misuse of the object. The answer is simple: Don't do that.
However.... Globals are great when they represent things that truly are available everywhere in the program.
If that is the case, and a global variable is the answer to your problem, don't force your code into a solution that doesn't fit.
If the right solution is a global variable then use it without guilt.
