Static or global in this case?

[Ganoosh]

I'm making a base framework for an OpenGL game I'm making for Windows, I'm currently using the HWND, HDC and HGLRC as static variables in WinMain, so I have to pass them to other functions if I want to use them. Would it be better to make the global so I don't have to pass them or should I leave them static? Also, what is so bad about global variables besides that they take up memory right at the beginning of the program? Statics also always have memory allocated so does it matter?

[Fordy]

It's often more a question of taste. Global variables can be helpful in many situations as they avoid the need to pass variables across function calls (sometimes this is just convinient, other times it may give a slight speed advantage), but they can sometimes lead to problems, especially for larger projects. It's better to couple variables with the functions that use them

[LuckY]

Ditto what Fordy said. In addition, it is generally considered bad programming practice to have global variables/objects, however, there are some situations where you have no alternative (for example, in an MFC app you _must_ have a global CWinApp object), but if you aren't forced to, you should, at a bare minimum, do whatever you can to keep your variables restricted in scope. Even some built-in global objects are restricted in scope via exploitation of namespaces (consider cin and cout, for example). You should never make a variable global to avoid the inconvenience of passing them across scopes. That is not only a poor practice but takes you to a lower level of lazy programming.

[valis]

There are many times when global variables are quite useful, in my opinion windows is a great example because it really offers no decent way of interprocess communication because it lacks signals. Windows messages can't really be compared because as far as I know you can't send a message to a process and you can't enumerate windows from a process id. Globals and shared memory really help (though still less powerful in my opinion); globals are 'bad programming' because it is rather opposite of encapsulation which people have come to expect when expanding pre-written code or using a library.
I believe some people will do stupid inneficient things just to avoid using a global variable or an unconditional jump, but both have their place. Use a global variable if it is convenient and will simplify the code, pass it to a function if that would make the function general, just don't go out of your way to avoid something that really makes sense.

[Gravedigga]

because it really offers no decent way of interprocess communication because it lacks signals

I can't agree with valis.
Windows offers plenty of methods for interprocess comm. There are pipes- named and unnamed, mailslots, simple message for GUI-apps, I think it was WM_COPYDATA or something like this, shared memory, sockets, Windows clipboard and many other like COM and so on(there could be some that I don't know about).

Can you name so many means of interprocess communication under any other OS?

[valis]

I think I worded that wrongly, I meant it has no great event driven means of communication, they offer a very small set of signals simply for compatability, but those are rather useless, one could argue messages are parallel, but I find them to be less powerful. Sockets, pipes, and shared memory are standard for a full fledged OS.
I won't argue that windows is a great os, as are the various unix and linux flavors, but I do find some frustration when confronted with a problem that could be easily solved by signals.

In any case, I think for things like thread communication, a simple global can greatly decrease complexity.

[novacain]

>>I meant it has no great event driven means of communication,

Look at HWND_BROADCAST msgs

Allows you to send custom defined msgs between applications.