1

Why are global variables considered bad practice in C++? Is there a time where they are acceptable to use? If so when, and where? Ive heard mixed answers to this question, some say if it works it works, and others tell me to avoid using global variables as much as possible.

Ed S.
  • 122,712
  • 22
  • 185
  • 265
John Snow
  • 87
  • 11
  • 1
    If it works, it works, but it's a horrible maintenance nightmare.* FTFY – chris Jan 07 '14 at 21:10
  • Global variables pollute your namespaces. They also do not conform to the precepts of "data hiding" or "encapsulation". – Elliott Frisch Jan 07 '14 at 21:12
  • question: when a global variable gets allocated and deallocated ? – user2485710 Jan 07 '14 at 21:15
  • 2
    If you are just starting out and writing programs a few tens or hundreds of lines long they work just fine. The costs don't really become apparent until you are writing bigger pieces of code and trying to reuse bits that you wrote before. Now is a good time to establish good habits with respect to global *everything*: be suspicious of installing anything global. – dmckee --- ex-moderator kitten Jan 07 '14 at 21:20
  • Congratulations in not showing any research effort whatsoever. – Shoe Jan 07 '14 at 21:22
  • 1
    Voting to close this question as opinion-based is weak. There are legitimate reasons why using globals can make programs harder to maintain. Closing it for other reasons is another story. – John Dibling Jan 07 '14 at 21:39
  • Useful thread regarding your question: http://stackoverflow.com/questions/484635/are-global-variables-bad – Lies Jan 07 '14 at 23:18

2 Answers2

1

Besides polluting the global namespace (which means code someone is writing that includes the declaration of such a global, might introduce a bug because it's referring to your symbol unwillingly), there is the Static Initialization Order Fiasco. A global is not static per se, but in any case the biggest problem is ensuring a valid state before first use.

Aside from that, global state is difficult to reason about and has the nasty side effect of watering down a strict separation of concerns in the code. Which leads to... Spaghetti monster of sorts.

Trust me, rewriting your code to use local variables instead will force you to clean up your design, and better code is a free result.

rubenvb
  • 74,642
  • 33
  • 187
  • 332
1

There are several reasons why people often advise against using globals, but fundamentally they all center around maintennence. Programs that use globals are much harder to maintain than programs that don't.

For one, they introduce state to the entire application. This makes is much more difficult to find bugs that result from code reading from or writing to these variables that you didn't intend, or at a time when you didn't expect. This becomes more difficult the larger the application becomes. The more interractions with a single global there are, the more complex the application becomes and the more difficult to understand.

For another it becomes more difficult to make multithreaded access safe and efficient. Can you lock down one of these variables without locking down the entire application?

Using globals also obfuscates ownership semantics. Who exactly owns these variables? When should they be created? When should they be destroyed?

It is of course possible to write correct programs using global variables. These programs are easier to write (excepting threading issues), but tend to become much more difficult to maintain. Forcing yourself to not use globals makes it sometimes harder to write the program in the first place, but it also puts many of the issues to rest early and finally making these programs easier to understand, debug and extend.

John Dibling
  • 99,718
  • 31
  • 186
  • 324