Global Variables

[zaqufant]

I know everyone preaches against the evils of global variables. But, I don't think I've ever been sure why they're bad. Is it to avoid name clashes in programs? Is that the only reason global variables are bad? Or why are they so bad?

[biggoron]

It goes against encapsulation, which is the idea that all data should be as invisible as possible to everything. That is, data should only be visible where it is necessary to be visible, and no-where else. Then again, I'm not sure why encapsulation is so important, just that it seems to be important

I guess it depends on whether or not you fear 'raptors.

[charlie]

Encapsulation is important in part because it helps you maintain control over how and when data gets changed.

If you have a global variable, then any code can change that value at any time. It is much harder to keep track of when the data changes. It is also much harder to add functionality. If you want a change to some data to trigger an event, encapsulating that data will make implementing your code easier. If you just have a global variable, then you'd have to find and change all code that modifies the variable and somehow ensure that any new code that needs to modify the variable also triggers the event.

There are other reasons, too, I'm sure.

[oulyt]

geez. i better stop using global variables then >.<

[zaqufant]

Say you make a struct that has all the variables you need for that program. So, you make one instance of that struct to organize all the variables you need for that program, is that a good solution for global variables. This way you only have to pass one variable to each function that need those variables, and the class can still be local to main. So like:

Code:

stuct Program
{
  int size;
  int numof;
  char* name;
  vector<BITMAP*> images;
}Program;

...
int main()
{
  Program program;
  ...
  while(not finished)
     UpdateProgram(program);
  ....
}

So is it ok to organize all the individual pieces of data you need in a struct that you will only use once? Is this a good solution?

[biggoron]

I don't think changing how you pass it around really changes the level of encapsulation:

Code:

struct AllVariables
{
    int a, b, c;
};

void doSomething(AllVariables& x)
{
    x.a = x.b = x.c = 1;
}

int main()
{
     AllVariables x;

     doSomething(x);
     return 0;
}

Code:

int a, b, c;

void doSomething(int& x, int& y, int& z)
{
    x = y = z = 1;
}

int main()
{
     doSomething(a, b, c);
     return 0;
}

Small difference, it's all still visible, just with your way it has to be explicitly passed.

[ih8censorship]

the x within the main function can't be "seen" by the doSomething function unless it explicitly passed to it. That's generally a good thing.  Though it is because of how you've scoped things there hehe sorry just had to poke. 

I think changing how you pass things might change it a little bit, but it's more about scope than anything really.

I think encapsulation is good because I think it enhances changeability. If data is tightly encapsulated, you should be able to remove the implementation (leaving the interface) and create a new implementation without issues like having to deal with a ton of now undefined variables. You'd only need to worry about a few function calls, to keep everything in the rest of the program working smoothly.

Also, being the security nerd i am (security is like one of my fun side computer hobbies haha) I say that it helps from that standpoint as well because if you have say a buffer overflow issue, encapsulating your data should minimize the area that an exploit could effect. I don't know for sure on that one, but it sure makes good sense. If I'm wrong please correct me though.

[charlie]

The struct does have benefits, but if you use an instance of a struct as a global variable then you have the same issues you have if all the members were global.

Note that you have two instances of Program in that code. One is global and is named Program and the other is local to main and is named program.