Thread: Global Varibles

Originally Posted by motocross1

Are you happy now?
How about ending the thread, jerk?

Never. I continue to pray for you.

Originally Posted by motocross1

There are 3 groups of people who come to this forum:
1) Students
2) Professionals who help the Students
3) Me - Someone needing information, not advice

Then what am I? I'm student. I help students, but I'm no professional. I form a 4th group! The group of "Hobbiests who help the Students and other hobbiests"

Originally Posted by motocross1

The forum's own website:
FAQ > C++ Namespaces - Cprogramming.com

WOW, I beat you guys.
I can't believe it.

Not exactly. There are no global variables in that article. Namespaces are primary applied to types, not instances. Yes, you could declare a variable in a namespace, making it effectively a global, but that's the same bad practice.

Put another way: yes, your classes are defined globally. Of course. Just like types such as "int" are defined globally. That's not the same thing as a particular int instance. Eg, C++ strings are defined in the standard namespace (hence, accessible globally as std::string, a type). But AFAIK, there are no global variables defined in the standard namespace.

Basically you are conflating objects with classes, but I am sure you know the difference. Going back to something from your post #22:

Code:

struct myStructData{ string name; int num; bool isReady; };
extern vector<myStructData> StructData;

Defining struct myStructData globally* is fine and dandy. Probably necessary.** It's declaring vector StructData globally that is the issue.

* or in a namespace, which is better. The type is still globally accessible, like std::string, but organized into a collection of related things. This way, if you declare a type such as myStructData in namespace myNamespace, you can declare a totally different myStructData in some other namespaces and the names will not collide. That's the point of namespaces. Otherwise, in a large project using a lot of third party libraries, everyone would have to be paranoid about the names they used for fear of redefining something with the same name somewhere else.

** you can nest a class definition inside another class definition, making it an inner private class which is not available globally. This is a good practice if the class has no application beyond the class it is nested inside. You can do the same thing with structs, typedefs, etc.

Make sense?

Originally Posted by motocross1

Feel free to explain why namespace exits if a class can "encapsulate" everything.

Feel free to explain what is encapsulation and what are namespaces, and the reason will become obvious

Originally Posted by MK27

There are no global variables in that article.

There are two "global variables" in that article, but they were declared in an unnamed namespace. Consequently, they suffer from the same problems as global variables of the "declared extern" variety, but with the mitigating factor that the reader only has to be concerned about the functions in the translation unit changing them.

Originally Posted by MK27

Namespaces are primary applied to types, not instances.

I would rather say that namespaces are just a way to group names so as to avoid name collision.

Originally Posted by MK27

But AFAIK, there are no global variables defined in the standard namespace.

std::cout and std::cin are effectively global variables in the std namespace.

Motocross1:

Aside from the very critical and important points that some of the other guys have made about encapsulation and coupling, there is another downside to using globals. When declaring a global variable you're adding that variables name to the global namespace, which essentially means you can't use that name for anything else if you want your code to be readable or understandable at all.

Consider the following code:

Code:

#include <iostream>

int myNumber = 8;

int doMath(int myNumber = 5)
{
	myNumber += myNumber;
	return myNumber;
}

int main()
{
	int myNumber = 3;
	myNumber = doMath(myNumber);
	myNumber += doMath();
	std::cout << myNumber;
	return 0;
}

One would have to step through the code line by line, or actually run it, to be certain of what the output would be. Now imagine that the variable isn't called "myNumber", imagine that it's called "index" or "key" or "pi" or some other commonly used variable name. You're essentially removing that name from the pool of available variable names for all the code that is written after or before you declared that global variable, unless you don't mind the source looking like my above example. This means you will have to pick less fitting names or resort to some obscure pseudo-hungarian naming scheme (such as "g_index"), which in turn means your code will become less readable.

This isn't the only problem. Imagine if you were ever to write some code that was to be reused by someone other than you, if you put global variables all over it, it is more than likely that there will be some sort of naming conflict when someone else has named their function the same as one of your global variables. Now i know you've said that the code you are writing is only for yourself, but you might aswell start learning proper techniques now. If you stick with global variables now, you will have trouble down the road when someone demands that your code lives up to some form of expectations. (Such as being even slightly readable)

Now all this i wrote is only partly why global variables are frowned upon, as others have stated that there are other more critical problems with global variables.

Also on a sidenote, you seem to think that "the professionals" on this board are trying to force you to structure your code according to some strange illogical agenda. Just know, that global variables are frowned upon not only on this board, but in the entire professional computer-science industry, globally.

Even the Wikipedia article on the matter speaks poorly on global variables. Take a step back and think about this, the entire world disagrees with you, maybe you should try and re-read this thread with an open mind, and actually make an effort to understand what some of the others have touched upon.

Or....you could continue to argue that you are right and the world is wrong.

Originally Posted by Neo1

maybe you should try and re-read this thread with an open mind, and actually make an effort to understand what some of the others have touched upon.

No tish. There is a ton of great information and explication in this thread. Motocross1, you are wasting a big opportunity to understand some fundamental concepts by not asking specific questions about the parts that are unclear! There is nothing wrong with saying, "I don't get this", or "could you explain this further", etc, rather than skipping over them and presuming (or pretending) that they must be irrelevant.