global variables - okay sometimes...?

this may not be the right board, but i didn't know what was... where should general programming topics go? anyway...

i started working on a pong game in allegro (i just needed a semi simple project, so i would actually finish something i started :rolleyes: ) and started wondering if maybe global variables were okay sometimes.. for example:
i have a struct for a paddle (containing coordinates, score, height and width...), a struct for a ball (coordinates, speed, etc), and a buffer to draw things to.. these all get used in many functions (drawing, moving, collission detection, etc...).
so, wouldn't it be easier to just make them all global, rather than passing them around to all the different functions? i fail to see the advantage of making them local to main, and passing them around...
it seems like it could even improve readability in some places... for example, i have a ballHit function, which checks if the ball has hit a wall, a paddle, or gotten past a paddle... if everything is local to main, i have to pass that function the ball, and two paddles... it seems like it would be better with global variables... anyone have any insights?

Personally, I don't see much wrong with global variables at all.

And technically, as long as the program compiles and works correctly, then whatever code you use is fine.

I agree. I don't see anything wrong with global variables as long as the code remains understandable. Unless you plan on having multiple balls bouncing around in there, I don't see a problem with keeping it global. That's my take on it, anyway.

i suppose they're not a big deal but a lot of people don't like them.

They are easy to get around though - just pass the variable to any function that would use it as a reference.

It is not just that global variables can be a little bit harder to read it is also that they are shared data. One function can change the variable in a way that is invisible to another function. This creates bugs that hard usually hard to find.

Remember this is C++ not C, they are not nessicary and are usually not used because they are not nessicary.

global variables make large programmers harder to debug, and in small programs it's okay, but still not recommended.

It's like saying you should just write everything in main, just because it compiles.

Anyways it's okay, but not something you should get a habit of.

large programs, not large programmers :D

It sounds like you're writing this program in order to learn more about programming and improve your skills. If that is the case, I woudln't suggest getting into bad habits like using global variables. As others have already said, they make larger programs very difficult to debug. However, if your aim is merely to make yet another pong clone, then whatever works works.

I think a programmer who is still learning should get used to certain things like using only local variables. What is easy is not always best, and what is best is not always easy.

Hmmm, I think that was a quote from someone or other, but I can't think who:p

Quote:

---

Hmmm, I think that was a quote from someone or other, but I can't think who

---

No matter who said it, it is still true.

Quote:

---

Originally posted by Munkey01
No matter who said it, it is still true.

---

Yeah, but if no one else said it first, I'm laying claim to it:p:D

thanks for the input, everyone.
this is more like another pong clone than improving my skills. i'm fairly good at programming.. not great, but good enough to know what not to do (most of the time ;) ). i normally avoid global variables, and i think this is the first time i've used them (since i learned the difference, anyway). i'm only using them here because i think it will make the program more readable/simpler/something...
i'm not really going for really neat and tidy code here anyway... if i were, i would probably make some classes and things.

Heh... a pong program sounds like a neat thing to make... I might try it for my own learning purposes (only I'll either use structures or classes).

As for global variables... about the only thing I use them for is constants (like a constant number for the pong's ascii character, etc).

global variables/ cumbersome passing of many parameters - this is just itching for a class. Classes will encapsulate the data from the outside world, while giving free access to it's member functions. you've got your ball and paddle structs, well why not make a class called board or game, and have the ball and paddles be data members and have public functions for collision, hitting the ball, changing direction/speed etc. These functions will have access to the ball and paddle variables (like they were global) but they won't be accessible from outside the class. Voila! no cumbersome var passing, and no global variables.

-Futura

Quote:

---

And technically, as long as the program compiles and works correctly, then whatever code you use is fine.

---

Until you have to maintain it later. :)

Quote:

---

I don't see anything wrong with global variables as long as the code remains understandable.

---

Global variables can lead to being functions and classes being very dependent on eachother, this is not really what you want.

Quote:

---

and in small programs it's okay, but still not recommended.

---

I agree, learn to avoid global variables, that habit will help you a lot when creating and maintaining larger software later. This does not only count for object oriented languages where things like encapsulation are important, but also in procedural languages and even functional languages data hiding is an important concept.

i finished it *claps* :D i think this is my first finished game, so it feels pretty good.. even if it is pong ;) :rolleyes:

i ended up using local variables and passing them around, because that's the way i started the project, and didn't feel like going to global variables, as it ment changing every functions parameter list, and probably a bunch of bugs from things i forgot to change.

>>this is just itching for a class.

i know. i may go back and do it with classes, but it's kind of doubtful... i'll probably never look at the game again after this. it was really just something simple so that i could finish it (and i did.. yay :D).

>>Until you have to maintain it later.

i won't ;)

future projects i'll most likely do with classes.

thanks for the input everyone.

Could we have the source?

>Could we have the source?

heh.. not in it's current state :rolleyes: i'll have to clean it up some, and maybe comment it a bit... i'm just finishing up the scoring and everything, so i'll try to post it later today.

//edit: source is up.. you can get it from that thread where people post their best games :rolleyes: (in the gaming forum)

Heh... My class version right now only has a ball and is ASCII (don't know graphics and don't really have the time to learn... college starts again in about a week).

As for globals... it uses them for the screen's size and for the ASCII character that represents the ball (I'm using #define ).

Quote:

---

Originally posted by Frobozz
(I'm using #define ).

---

Why not use const?

Good question... I'm just using it because I've seen it used a lot in a friend's code and also in my professor's code (even though I haven't taken his class yet).

Is const better? Does #declare allow stuff to be used regardless of data type?

when you use #define such as in the form
#define PI 3.1415926
then PI will be treated as though it is a float.
PI could also be declared as
const float PI = 3.1415926

Not much difference, though one is a const global variable the other is a #define statement

Later,

Quote:

---

Originally posted by WebmasterMattD
when you use #define such as in the form
#define PI 3.1415926
then PI will be treated as though it is a float.
PI could also be declared as
const float PI = 3.1415926

Not much difference, though one is a const global variable the other is a #define statement

Later,

---

Actually, it would be a double, not a float.

#define doesn't obey scope rules, so you shouldn't use it much. There are only very few places you should have to use #define, and this is not one of them.