Sign in to follow this  

What's wrong with globals? (philosophical question)

This topic is 4663 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

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
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
Guest Anonymous Poster
@Magmai Kai Holmlor

Could you clarify what exactly do you meant by the following?

" In some environments (particularily constrained Harvard architectures) ..."

When i come across the term harvard architecture, I'm thinking seperate memory spaces for code and data. Is this what you are refering to? and what exactly do you mean by 'constrained'?

Share this post


Link to post
Share on other sites
If you're using C++ (as opposed to C) I think static is deprecated as a means for creating file-scope variables, you're supposed to use an anonymous namepsace instead I believe.

-Mezz

Share this post


Link to post
Share on other sites

This topic is 4663 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this