I am starting to think that the use of globals is not evil in itself. It is a problem of scale and scope. To take an example, which is unrealistic but possible:

Take a C program "PROG" where every heap allocated variable is globally defined. This kind of application is the way programming was done in the old days, before object orientation and ADT was invented (please allow me the simplification). This PROG will be hard to maintain and inflexible when it grows. If the complete source code fits into one screen, it should still be fine. However, as many found out, when PROG grows there is point when maintenance gets unreasonable. It simply takes too much effort to do changes, with severe side effects making it hard to guarantee correctness.

If this big PROG is packaged into one single huge class in C++, it will fulfill the requirement of not using globals. But the basic problem still remains, which is a problem of scale. Parameters in a class can be just as problematic as global parameters, if the class is too big (bloated, fat class, ...).

From that point of view, stating that global variables are evil is a simplification? The real problem is the size of the scope where a variable (or function and sometimes type!) is available. But I suppose it is much easier to explain "Don't use global variables", than to explain that scopes shall be kept to a minimum size.

I try to design without globals in mind, but things like debugger/profiler that I have to use and I _need_ access to it from basically every part of my code to dump something on the screen or profile execution just require some kind of global var / singleton (which I don't like and prefer just typical global variable). I tried hard to figure how to pass it around and having it passed through all object chains because I may need it at some point is just plain stupid IMO.

Instead I just create a global instance of Debugger class and in any .cpp file that I need access to it to dump some data or profile part of the code, I use extern. I really can't see how this can be done better - I can't use global functions because I need a state (debug drawing requires geometry to be compiled and drawn each frame etc, so instead of one class I'd have to get some global variables anyway and it will be ugly). Its also only for debugging, so in release mode my code is global free anyway.

I think people who are 100% against globals are some hard to convince OO-freaks.

Where are we and when are we and who are we?
How many people in how many places at how many times?

Take a C program "PROG" where every heap allocated variable is globally defined. This kind of application is the way programming was done in the old days, before object orientation and ADT was invented (please allow me the simplification). This PROG will be hard to maintain and inflexible when it grows. If the complete source code fits into one screen, it should still be fine. However, as many found out, when PROG grows there is point when maintenance gets unreasonable. It simply takes too much effort to do changes, with severe side effects making it hard to guarantee correctness.

Very true. It's important to know why things can be problematic rather than just that they can be problematic. This frees people to make more enlightened decisions about design because they learn the underlying problem (and how to fix it) rather than just the rule.