Jump to content
  • Advertisement
Sign in to follow this  
Oberon_Command

What's wrong with globals? (philosophical question)

This topic is 4849 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

In quite a few programming books that I've read (mostly by Andre Lamothe), globals are used quite extensively. But when I go only, it seems like most people hate globals. My question is, what's so bad about globals?

Share this post


Link to post
Share on other sites
Advertisement
I believe it's considered too easy to accidentally change the value from a different part of the program. Considering that a well designed program shouldn't really need any, I guess most people prefer to avoid that very small risk.

Share this post


Link to post
Share on other sites
Globals go aganst OOP. They can be accessed from anywhere, which breaks encapsulation. You can't define the construction order of globals (Well, you can, but only ones in the same source file), which can lead to some nasty bugs that only show up on some compiled.

I often use globals for quick projects, and sometimes I have a global HWND or something, if I can't be bothered writing pBlah->GetWindow() all the time.

A lot of source code examples you see on the Internet use globals for clarity. They're often trying to show you how to do one thing (e.g. create a window), and don't want to confuse the code by OOPing it up too much.

Share this post


Link to post
Share on other sites
Globals violate encapsulation. It is nearly impossible to maintain invariants on globals. People forget, and do stupid things with globals. Generally, anything extra you must keep track of just wastes your time. People can only have about 7 things in their 'working memory' at once. Remembering your globals just wastes space.

Share this post


Link to post
Share on other sites
Learn the words "Least Privaledge." Global variables are publically availiable to everyone that uses the extern keyword. Sometimes, every corner of the entire program needs access to a global set of variables. Other times, a variable is only needed in a few places, and only changed in one. Encapsulation or "Least Privaledge" assures some basic security on the variables. Its a matter of self-discipline, and dealing with compiler errors rather then obscure logic errors during run-time that take hours to debug.

Share this post


Link to post
Share on other sites
Apart from the encapsulation/OO design issues, globals can also become a performance issue. Because they are, well, global, they have to be kept up to date in memory at all times. (Because each function is compiled separately, and the compiler has no information available about when the global is going to be accessed, so it usually has to assume it might be accessed, and so store an updated copy in memory).
If the variable is used frequently, that's a lot of extra memory access.

Of course it's possible to make a compiler that can handle this, but it'll get very complex, especially in larger programs, and I don't think any of the existing popular compilers can do it.

Share this post


Link to post
Share on other sites
There is no guarantee that globals have volatile storage, and a compiler is free to keep a global in registers for as long as it feels like it. You might be considering aliasing rules, where any function called by another function could be assumed to change global state, so globals are implicitly aliased outside of the scope of the current function.

You can think of globals as non-const reference arguments that are implicitly passed to EVERY function in your program. How many such arguments do you think each function should have? :-)

Share this post


Link to post
Share on other sites
Just as a side note, you can declare static globals, which means that only the file in which they are defined can access them.

Share this post


Link to post
Share on other sites
Least priviledge makes refactoring easier, too. In Java, where your class definition is contained entirely in the file and you normally have only one class per file (you can have more but then they can't be public classes, and non-public classes often aren't too useful), and you need to check up on all the uses of a data member (because you're going to do some refactoring, or you think it's become dead code and you want to get rid of it), and the member is private, you know that you only have to look at the current source file to find all its uses. That makes it a lot easier to prove that you can get away with doing whatever it is you're about to do. :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Holy Fuzz
Just as a side note, you can declare static globals, which means that only the file in which they are defined can access them.


Those aren't really globals, globals need to have external linkage which is where all the issues come from. But building on this idea, you can declare storage at the file level (should tag it static) and expose access to it through functions (which implicitly have external linkage). In some environments (particularily constrained Harvard architectures) this is very useful because it let's you statically allocate your storage and place it in code segement (typical advantages of true globals).

Quote:
hplus0603
There is no guarantee that globals have volatile storage, and a compiler is free to keep a global in registers for as long as it feels like it.

Can't you tag it 'volatile'? That (combined with a linker 'trick') is how memory mapped registers are typically accessed. volatile unsigned int special_reg;

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!