Theory Question: Global Variables

From what I've come to understand, we don't often use global variables because we want to preserve the name in case we wish to use it for a different, but similar purpose later on in the program. However, I've found in programming, that, at times, some variables only serve one purpose throughout the program and often have to be passed to function purely so they can be passed to other functions that need them and always because they need to use the same named variable, in a different spot.

Wouldn't it make more sense then to put those variables in a header file and make them global?

For example:

Let's say I have a menu variable that contains all of the default menu attributes for a menu system, or a character variable that records every aspect of a character. Rather than reference the variable everywhere, why not make it global?

Really the main reason for avoiding global variables is to avoid global state. It can make your program more difficult to debug since a global can be modified from literally anywhere in the program. It can make it difficult to reuse code, since it isn't going to be clear what globals are required for code to work correctly. It can also lead to "lazy" designs that are more difficult to modify or maintain. Take your character example for instance - what if you decide later that you want to have two characters instead of one? 5 characters? A random number? Since all of your code dealing with characters is tied to this global variable, now you're going to have to go back and modify all of it in order to support the new design.

Now, there are some people who religiously hold the view "no globals at all, ever, period, no exceptions", but most people tend to agree that there are times when it's simply easier to use a global and be done with it. For example, cin and cout in the standard library are global stream objects. It's also common to see things like loggers set up using globals.

I echo Speedo's points.

I'd like to add this to the perspective.

When decided what classes to fashion, it's instrumental to keep in mind that they model or represent concepts as metaphors. The more 'real' we can make that metaphorical representation of concepts, the more like a machine our software becomes - the properties of components fitting together to create a larger machine.

Global variables violate this notion of encapsulation. If they're genuinely appropriate as global variables, it would be because these variables represent global concepts - that for which there can be only one for the entire application.

If the concepts these variables might not always be global, as speed points out, then at best they should be members of an object which we instantiate once. This encapsulation makes them portable as a group into other environments which aren't always global in concept. That is, they may be global in a simple application, but not always global in future developments.

The biggest problem with global variables is they increase coupling and impede code modularity. This makes it much harder to reuse code using globals. If the value of a global variable cannot be worked out at compiletime and instead is initialised at runtime there can also be initialization order issues.
Basically you should try to avoid using globals as much as possible. What you see now as convienience, may in fact be a complete headache as your project grows larger.

I guess I'll learn from my mistakes and try it out. I do think in this instance it will work. But I think I'm of some of the same mind in why they are bad, though I haven't run into many issues yet still being new to the coding thing.

Update: I'm getting all sorts of errors when trying to turn the variable global. It's frustrating enough to make me want to stop since I know people are going to be hesitant to help me get them working since people are against them in the first place.

My question is: Is it common practice to see variables in a program that go in almost every function just so that they can be passed to other functions just because they are so relevant as a variable? That seems needlessly inefficient for variables that you know there is only ever going to be one instance of across an entire program.

Quote:

---

Originally Posted by BleaS

Update: I'm getting all sorts of errors when trying to turn the variable global.

---

What are the errors.

Quote:

---

It's frustrating enough to make me want to stop since I know people are going to be hesitant to help me get them working since people are against them in the first place.

---

Why not show your code? You've just described what you're doing, but none of us know exactly what you are trying to do.

Quote:

---

My question is: Is it common practice to see variables in a program that go in almost every function just so that they can be passed to other functions just because they are so relevant as a variable?

---

No.

Good C++ programmers encapsulate that entire design into a class or several classes. If such a variable is so important to an entire program, it begs the question of why the "program" is not a self-contained class or set of classes, where that global is just a member variable.

It sounds like you should be creating a class instead of "globalizing" your application.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

What are the errors.
Why not show your code? You've just described what you're doing, but none of us know exactly what you are trying to do.

---

I can.

Code:

---

Character.h

#ifndef GUARD_Character_h
#define GUARD_Character_h

extern struct Character {
        int Curr_x, Curr_y;
} Curr_Char;

#endif //GUARD_Character_h


Character.cpp

#include "Character.h"

Character Curr_Char;

Curr_Char.Curr_x = 0;
Curr_Char.Curr_y = 0;

---

Errors:

Code:

---

character.cpp(5) : error C2143: syntax error : missing ';' before '.'
character.cpp(5) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
character.cpp(5) : error C2371: 'Curr_Char' : redefinition; different basic types
        character.h(6) : see declaration of 'Curr_Char'
character.cpp(6) : error C2143: syntax error : missing ';' before '.'
character.cpp(6) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
character.cpp(6) : error C2371: 'Curr_Char' : redefinition; different basic types
        character.h(6) : see declaration of 'Curr_Char'

---

Quote:

---

Good C++ programmers encapsulate that entire design into a class or several classes. If such a variable is so important to an entire program, it begs the question of why the "program" is not a self-contained class or set of classes, where that global is just a member variable.

It sounds like you should be creating a class instead of "globalizing" your application.

Regards,

Paul McKenzie

---

I'm in the process of learning, I don't know anything about classes yet. However, I am at a point where I can do things that seem to suggest the use of something like a global variables.

Best practice:
Try to localize variables. Make them as local as possible.

For more info I'll recommend to read Shatter & Alexandrescu books and Allen Holub's Enough Rope to Shoot Yourself in the Foot. Mr Holub, for example, recommends to limit the number of global variables to about ten.

From my modest knowledge and experience
1) When programming for WinAPI it makes sense to make hThisInstance and hDllInstance global i.e. copy thier values into g_hThisInstance and g_hDllInstance respectively.
2) If you worry about intensive stack usage when dealing with recursion put the function to separate module and make the arguments static.
Important note /need multithreading guru help/:
It also seems me that using global variables makes your code multithreading-incompatible.
3) You could use static fields of classes.
4) Then dealing with huge number of global variables you need strict naming conventions. Then you localize your identifiers you shouldn't worry about that as C++ doesn't allow to create identifiers with :: and . inside.

Try this:
Character.h

Code:

---

...
typedef struct
{
    int Curr_x, Curr_y;
} Character;
...

---

Character.cpp

Code:

---

...
Character Curr_Char;
...

---

You should to know the things I've omitted.

The major issue for me is that I find myself passing certain variables through EVERY function, even if the nature of the function doesn't seem to involve them. Just because it needs to go to another function.

It didn't seem efficient or what coders would stand for. But, from what I understood, the answer was classes. Classes aren't what I know yet, not for a few chapters. But I need to practice what I do know as much as I can, and I want to do it making programs that are interesting to me, so sometimes I have to go beyond what the book gives as an example. However, I know everything I need to make this program, the issue is trying to go a further step and not waste my time on redundancies.

Quote:

---

I'm in the process of learning, I don't know anything about classes yet. However, I am at a point where I can do things that seem to suggest the use of something like a global variables.

---

The title of the thread is a theory question on global variables. The answers given to you so far all state to only use globals if necessary, and if so, to sparingly use them.

What you are describing, having to pass a variable to certain function, is what classes are designed to solve. That variable would have been a member of a class, and then you don't pass anything around since that variable is part and parcel of the class you're implementing.

Quote:

---

The major issue for me is that I find myself passing certain variables through EVERY function, even if the nature of the function doesn't seem to involve them. Just because it needs to go to another function.

---

Then learn classes. Again, that is the real solution to the problem you're describing.

What you're stating is no different than this scenario:

You write a program that declares 100 integer variables, say int1, int2, int3, int4, ... int100. After you write the program you say (justifiably) "this is very tedious work doing the same thing for 100 integers -- could I use #define macros to make the code easier?". One of us would say to you "learn arrays and indexing, not macros". So you learn to use arrays and indexing -- you shouldn't continue using 100 separate integers just because simple types are the only thing you happen to know at the moment and you may have read something on #define.

Regards,

Paul McKenzie

Arrays seem a bit less complicated than learning classes. It doesn't seem to be reasonable to skip the learning progression to learn classes when they're much more to deal with and complicated than learning to use arrays over 100 integers.

I think, now understanding what people are using, that I will simply stick to passing through the variable in every function. It sucks, it wastes time, but it will motivate me to keep learning until I get to classes, and being able to move past rudimentary, novice coding.

Quote:

---

Originally Posted by BleaS

Arrays seem a bit less complicated than learning classes. It doesn't seem to be reasonable to skip the learning progression to learn classes when they're much more to deal with and complicated than learning to use arrays over 100 integers.

---

You're missing the point.

The point I'm trying to make is that there will always be cases where something you learned will not work efficiently until you actually learn the correct way to solve the problem. It could be something simple as arrays, or as complex as policy-based programming using templates.

Regards,

Paul McKenzie

Until you actually learn classes, you can simulate a class object using global variables if:

1) You clearly demarcate a set of related functions which will use each global, and allow no others to do so.

2) If the set of functions needing access to a value is not conceptually groupable, consider whether writing a getVarName() function which offers read-only access to a global allows you to limit the set of directly-accessing functions to the point where they do form a clear conceptual group of operations. (Read-only access to a global int, for instance, could be achieved by returning a "const int&" from the function. Likewise for any type.)

3) Your conceptual function grouping can be thought of as a single object, machine, or agent in the system. Don't worry about precise definitions----it just needs to represent a "thing which does stuff." It should be conceptually possible to have more than one of these things, but you cannot support actually having more than one until you start using classes.

I thank everyone for their input, and Paul, I do get it, which is why I'm motivated to follow the progression of learning that's been set out until I do classes. Until then I'll have to make do.

Quote:

---

Arrays seem a bit less complicated than learning classes.

---

Arrays are not a part of a *programming paradigm*. In simple words paradigm is a way of thinking. The paradigm you know in procedural programming. C++ supports many: procedural, object-oriented, generic, this I know maybe some more. You have to know arrays to deal with any modern programming language. By the way all the OOP could be imitated with means of procedural programming.

But I would like to continue our talk about global variables:

Here are Google coding standards (I've found them a long time ago and remembered about them now) and some quotes from them:
http://google-styleguide.googlecode....k/cppguide.xml

http://google-styleguide.googlecode....obal_Variables

Quote:

---

Static or global variables of class type are forbidden: they cause hard-to-find bugs due to indeterminate order of construction and destruction.

---

Forbidden is a weighty word. They are allowed syntastically at least.

andrey_zh was just quoting Google's in-house coding standards, which are about good coding practices (especially in a large team / multiple-programmer setting), not about what the language does or doesn't support.

Ah. Well, I think that would make a bit more sense on a team. Where the reading suggests that global variables increase program complexity, adding more people to the project compounds that, no? Would it be safe to say that global variables would be a no on any large-team project?

Remember too that Google's standards are written with Google's code in mind. They're useful as guides but you don't have to follow them verbatim. For example, they also forbid the use of exceptions, but clarify that that's mainly because their existing code isn't always exception-safe.

Quote:

---

Originally Posted by BleaS

My question is: Is it common practice to see variables in a program that go in almost every function just so that they can be passed to other functions just because they are so relevant as a variable? That seems needlessly inefficient for variables that you know there is only ever going to be one instance of across an entire program.

---

Some variables are global by nature. What you can do is to define accessor functions to get and set the global variables instead of using them directly. This adds a thin layer of abstraction. In addition you should minimize calls to these global getter/setter functions. Use them only when absolutely necessary, for example to avoid passing a variable through unrelated sections of code to the place where it's actually being used as you mentionen, because this creates unwanted dependencies between program parts too.

Regardless of whether you use global setters/getters or a more advanced method of managing global state, like the Singleton design pattern, it's still global state; Too much of it will make your program more error-prone so use it with caution.

You can rarely avoid global state altogether in a large program. There's even an object oriented way to handle it called the Singleton design pattern (which ensures that a class only has one instance and provides a global point of access to it).

Unfortunately Singletons are often overused. Especially unexperienced programmes feel they've got a carte blanche to make extensive use of global data just because there's an established OO way to do it. The best advice still is to use global state with caution.