What's wrong with globals? (philosophical question)
Author
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?
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.
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.
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.
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.
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.
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.
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.
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? :-)
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? :-)
Just as a side note, you can declare static globals, which means that only the file in which they are defined can access them.
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. :)
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;
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
