- Forum
- Windows Programming
- Do I have to use global variables?!?
Do I have to use global variables?!?
Pages: 12
closed account (3pj6b7Xj)
My Squibbles game is about 90% complete, code wise that is, then I have some debugging to do. Anyway, here is the issue I had last night. To move a snake up, down, left or right, you send the snake a command for example ... snake.move_left() or snake.move_right() ... so I put my key mappings into the window procedure but was faced with a rather interesting scenario.....my snakes were out of scope!! I used all my knowledge of C++ to try to find a way and PREVENT using global variables.....but I ended up making making the Snakes global so I could access them from within the procedure......I guess it can't be too bad, the Snakes are classes and they control their own data but I really hate using global variables, it makes programs unreliable ... got any input for me guys? Game is working fine now but i'm pretty sure there must be something I DON'T KNOW that someone does out there that I can put to use and probably kill the idea of the global variable ....... oh well ... i've done some DirectX programming and there was heavy use of global variables in that, specially with the created device...thanks for your support guys.
Have you tried passing the snakes by reference in your functions?
http://cplusplus.com/doc/tutorial/functions2/
-Albatross
http://cplusplus.com/doc/tutorial/functions2/
-Albatross
closed account (3pj6b7Xj)
How will that help if i'm trying to command the snakes to change directions from within the window procedure? The snake functions only take in a HDC device which is given through a function called init, the rest of the functions change data within the class. I know how to pass by reference, pointers and other bizarre ways id rather not talk about but that is not the point.
I can't command a change in direction from within the procedure.....at the window procedure, I intercept WM_KEYDOWN i trap my key of choice lets say its the up arrow and then I .... oh wait a minute.....oh darn I forgot all about GetKeyState functions totally over looked that. I can check for key presses at the main loop with that assuming it doesn't slow it down.
I can't command a change in direction from within the procedure.....at the window procedure, I intercept WM_KEYDOWN i trap my key of choice lets say its the up arrow and then I .... oh wait a minute.....oh darn I forgot all about GetKeyState functions totally over looked that. I can check for key presses at the main loop with that assuming it doesn't slow it down.
GUI programs don't need global variables. None. Nada, Zip. Nichts. I've posted a lot of my code lately. Can you find any global variables in it? If you do let me know and I'll remove it.
closed account (3pj6b7Xj)
The scenario I had was trying to modify a variable from the windows procedure......since variables inside WinMain are out of scope at the Window Procedure, how could you modify them when a user presses a key, etc.
I thought of the idea of using SendMessage with the right parameters and then trapping that message in the program loop and act as required but it seems quite slow. I've seen some of your code...
Lets say for example, I have a variable named
string dogname("pluto");
so now at the windows procedure, I trap WM_KEYDOWN in the window procedure and present a dialog box saying the dog name will be changed...i can't change dogname from the procedure because its out of scope but I CAN change it in WinMain ... however, WinMain some how has no idea that this event occured, only the window procedure knows......unless you send a special message but if i'm going to be sending messages, shouldn't I just trap wm_keydown in the program loop as opposed to the procedure?
I thought of the idea of using SendMessage with the right parameters and then trapping that message in the program loop and act as required but it seems quite slow. I've seen some of your code...
Lets say for example, I have a variable named
string dogname("pluto");
so now at the windows procedure, I trap WM_KEYDOWN in the window procedure and present a dialog box saying the dog name will be changed...i can't change dogname from the procedure because its out of scope but I CAN change it in WinMain ... however, WinMain some how has no idea that this event occured, only the window procedure knows......unless you send a special message but if i'm going to be sending messages, shouldn't I just trap wm_keydown in the program loop as opposed to the procedure?
closed account (3pj6b7Xj)
This is the reason why I wrote a template class that took a type and stored it in a variable. I called it the LockAfter<> template class...basically you could do this...
LockAfter<HDC> g_WinDC;
Then you assign the value to g_WinDC...
g_WinDC = GetDC(hWnd);
The interesting part is that once g_WinDC is initialized, it can no longer be changed and is locked. That is why I called it LockAfter, because you lock the variable from being modified after you assign a value to it.
For regular global constants like const int flags = 10; it is not needed but for handles like HWND & HDC which can't be initialized before WinMain LockAfter protects the variable from modification by locking it once its initialized......that way if anything tries to modify from anywhere else, it alerts you MessageBox(NULL,"Attempt to modify locked variable!","LockAfter",0);
I still hate globals tho and still interested in your information! The LockAfter template refreshed my memory of operator overloading and use of templates which I rarely use.
LockAfter<HDC> g_WinDC;
Then you assign the value to g_WinDC...
g_WinDC = GetDC(hWnd);
The interesting part is that once g_WinDC is initialized, it can no longer be changed and is locked. That is why I called it LockAfter, because you lock the variable from being modified after you assign a value to it.
For regular global constants like const int flags = 10; it is not needed but for handles like HWND & HDC which can't be initialized before WinMain LockAfter protects the variable from modification by locking it once its initialized......that way if anything tries to modify from anywhere else, it alerts you MessageBox(NULL,"Attempt to modify locked variable!","LockAfter",0);
I still hate globals tho and still interested in your information! The LockAfter template refreshed my memory of operator overloading and use of templates which I rarely use.
Last edited on
Are you familiar with these Window Api Functions...
SetWindowLong()
GetWindowLong()
GetProp()
SetProp()
GlobalAlloc()
GlobalFree()
HeapAlloc()
HeapFree()
The top two are used in conjunction with storing bytes as part of the Window Class Structure itself which you initialize in WinMain(). The .cbWndExtra bytes member allows you to allocate extra bytes in multiples of four bytes which can hold pointers or data itself (pointers to data are a better idea). However, to make use of this facility you must be very good with pointers. And I mean very good.
That is how object oriented programming is done in Win32. That is how data is 'persisted' across invocations of the Window Procedure. You must not have hardly looked at any of the code I posted for you or you would have clearly seen this, as it is a staple of everything I do. The whole purpose of that program I posted right before Christmas was to show how that was done. If you recall, there was a window which displayed mouse coordinates as you moved the mouse, characters as you typed, mouse button presses as you pressed buttons, etc. Now, all those events, i.e., mouse movements, keypresses, button clicks, etc., were picked up in seperate invocations of the window procedure. How do you think they were displayed which they were during a WM_PAINT message - which is a seperate invocation of the window procedure????????? Note I didn't call GetDC to draw onto the window as you appear to be doing (another wrong thing you are doing, I might add as an aside). The data was persisted across invocations of the window procedure by storing the data not on the stack (can't do that - it goes out of scope), but in dynamic heap memory addressable using pointers. Memory was allocated during the WM_CREATE message, used throughout the program, and released at program termination in WM_CLOSE.
Here's a scroll program. There are comments in the code and MessageBoxes explaining it.
//There Are No Global Variables In This Program!
SetWindowLong()
GetWindowLong()
GetProp()
SetProp()
GlobalAlloc()
GlobalFree()
HeapAlloc()
HeapFree()
The top two are used in conjunction with storing bytes as part of the Window Class Structure itself which you initialize in WinMain(). The .cbWndExtra bytes member allows you to allocate extra bytes in multiples of four bytes which can hold pointers or data itself (pointers to data are a better idea). However, to make use of this facility you must be very good with pointers. And I mean very good.
That is how object oriented programming is done in Win32. That is how data is 'persisted' across invocations of the Window Procedure. You must not have hardly looked at any of the code I posted for you or you would have clearly seen this, as it is a staple of everything I do. The whole purpose of that program I posted right before Christmas was to show how that was done. If you recall, there was a window which displayed mouse coordinates as you moved the mouse, characters as you typed, mouse button presses as you pressed buttons, etc. Now, all those events, i.e., mouse movements, keypresses, button clicks, etc., were picked up in seperate invocations of the window procedure. How do you think they were displayed which they were during a WM_PAINT message - which is a seperate invocation of the window procedure????????? Note I didn't call GetDC to draw onto the window as you appear to be doing (another wrong thing you are doing, I might add as an aside). The data was persisted across invocations of the window procedure by storing the data not on the stack (can't do that - it goes out of scope), but in dynamic heap memory addressable using pointers. Memory was allocated during the WM_CREATE message, used throughout the program, and released at program termination in WM_CLOSE.
Here's a scroll program. There are comments in the code and MessageBoxes explaining it.
//There Are No Global Variables In This Program!
|
|
|
|
You do have to run the program and study it.
Also realize that WinMain() is running in a message retrieval loop all the time your program is running, and you need to learn the use of the very last parameter of the CreateWindow() call, which is a pointer parameter. Look it up in the docs. With that last very important parameter you can pass data into your WM_CREATE handler. In fact, after a CreateWindow() call data can be passed back to the point of call through that last parameter. And none of this data transfer requires global variables. I've written massive applications with tens of thousands of lines of code and countless windows with no global variables.
Also, its very likely whatever you are doing with handles to device contexts obtained with GetDC() is wrong!
Also realize that WinMain() is running in a message retrieval loop all the time your program is running, and you need to learn the use of the very last parameter of the CreateWindow() call, which is a pointer parameter. Look it up in the docs. With that last very important parameter you can pass data into your WM_CREATE handler. In fact, after a CreateWindow() call data can be passed back to the point of call through that last parameter. And none of this data transfer requires global variables. I've written massive applications with tens of thousands of lines of code and countless windows with no global variables.
Also, its very likely whatever you are doing with handles to device contexts obtained with GetDC() is wrong!
closed account (3pj6b7Xj)
You are correct, I am doing so many wrong things...this is my code for the main on my Squibbles game, brase yourself.
|
|
closed account (3pj6b7Xj)
Part 2...
|
|
closed account (3pj6b7Xj)
oh boy...part 3...
|
|
closed account (3pj6b7Xj)
dont even attempt to compile that mess, you'll need createapp.h, leveldata.h, gamedata.h, texthdc.h, menusystem.h and god only knows what else. This version does not use that LockAfter template and my current game loop is not while (true) i use a bQuitToMenu bool for that but its not implemented in this version.
But clearly, my code is massive and unreliable for such a simple game. I wont degrade myself as the windows api is all new to me and i'm forced to use programming techniques i've never tried before.
Look at the code, EVERYONE look at the code, all your input is very much appreciated, this is the heart of my snake game and once its complete, I will tahnk you all, I should throw that intot he about box...for now read, critic, point out what im doing wrong, were I can improive, etc...I will be busy studying freddie1's code until I can write something of my own that is based on the idea, then...I will return to create Squibbles II I have to finish this mess as it is but i have learned a lot from it...now iits time for some feedback!
Thats it, comparing my style of programming to yours (freddie1), I don't stand a chance, I'm going to have to sit down and learn from it and possibly re-write the entire code in Squibbles.cpp, probably alsoo do away with some programming habits and throw some implementations in the trash, i've got a lot to learn, I will release Squibbles as it is for now, a re-write of all the code will cause a catastrophy right now.
pardon the typos and bad grammer its 3:49 am, I had awaken for a snack and decided to turn the lap top on and see whats new, good night guys, going back to bed here...
But clearly, my code is massive and unreliable for such a simple game. I wont degrade myself as the windows api is all new to me and i'm forced to use programming techniques i've never tried before.
Look at the code, EVERYONE look at the code, all your input is very much appreciated, this is the heart of my snake game and once its complete, I will tahnk you all, I should throw that intot he about box...for now read, critic, point out what im doing wrong, were I can improive, etc...I will be busy studying freddie1's code until I can write something of my own that is based on the idea, then...I will return to create Squibbles II I have to finish this mess as it is but i have learned a lot from it...now iits time for some feedback!
Thats it, comparing my style of programming to yours (freddie1), I don't stand a chance, I'm going to have to sit down and learn from it and possibly re-write the entire code in Squibbles.cpp, probably alsoo do away with some programming habits and throw some implementations in the trash, i've got a lot to learn, I will release Squibbles as it is for now, a re-write of all the code will cause a catastrophy right now.
pardon the typos and bad grammer its 3:49 am, I had awaken for a snack and decided to turn the lap top on and see whats new, good night guys, going back to bed here...
Last edited on
Yes, I know you are learning mrfaosfx. Sorry if I sounded too harsh. Globals are one of my 'hot buttons', so I guess that set me off. If it helps, I used globals for I'd guess my 1st five years or so of Windows programming, until I finally 'saw the light'.
I may not have much time this weekend to look at your code, but I'll try next week. Please leave it posted.
I've re-written many programs from scratch myself. The way it works of course is you finally learn all the weak spots and problems of your code while doing it, then eventually start from scratch again after finally painfully finishing one somewhat poor version. Each version gets better though!
The code I post around here is somewhat hard to follow I imagine, because I don't use the standard switch construct to parse Windows messages dispatched to the Window Procedure. I use a function pointer setup and message cracker scheme I learned and modified for my use from Doug Boling who writes Windows CE books for Microsoft. He claims he learned the technique from another famous and advanced programmer named Ray Duncan.
If you are interested on that I have a tutorial on how it works here....
http://www.jose.it-berater.org/smfforum/index.php?topic=3391.0
Perhaps in the future when I post working programs I'll modify the programs to use the standfard switch construct so its easier to follow.
The other thing is, I fear a lot of folks learning C++ don't study function pointers. I feel they are important though, and are the basis for many advanced techniques.
I may not have much time this weekend to look at your code, but I'll try next week. Please leave it posted.
I've re-written many programs from scratch myself. The way it works of course is you finally learn all the weak spots and problems of your code while doing it, then eventually start from scratch again after finally painfully finishing one somewhat poor version. Each version gets better though!
The code I post around here is somewhat hard to follow I imagine, because I don't use the standard switch construct to parse Windows messages dispatched to the Window Procedure. I use a function pointer setup and message cracker scheme I learned and modified for my use from Doug Boling who writes Windows CE books for Microsoft. He claims he learned the technique from another famous and advanced programmer named Ray Duncan.
If you are interested on that I have a tutorial on how it works here....
http://www.jose.it-berater.org/smfforum/index.php?topic=3391.0
Perhaps in the future when I post working programs I'll modify the programs to use the standfard switch construct so its easier to follow.
The other thing is, I fear a lot of folks learning C++ don't study function pointers. I feel they are important though, and are the basis for many advanced techniques.
Several weeks ago after I posted some long winded explanations and a fair amount of code ComputerGeek01 mentioned that I might post a tutorial here. I think I'll do that. Something to augument Petzold and the Forger's Win Api tutorial. I believe this program below will be part of it when I get it done.
Anyway, here is an easier program for you to figure out when you finally get your game working as good as you can such as it is. The scroll program I posted above is something I was working 'hot and heavy' on this week, so I posted it but scrolling is inherently complex and not a good place perhaps to attack the global issue. Here, however, is a very short simple Windows program that should succinctly as possible show how globals are eliminated by using some of the functions I previously described. Also, there are lots of comments in the code, and it uses the standard switch Window Procedure construct instead of my tricky message cracker routine. The program just creates a three dimensional box out of a class named CBox with length, width, and height members, and of course there is a CBox::Volume() member function. Can't get much simpler than that. However, the program shows the proper way to persist private data across invovations of the Window Procedure, and the proper way to draw to the Window using BeginPaint() and EndPaint() during a WM_PAINT handler with no improper GetDC() calls involved.
I might mention that sometimes you just have to bear down and study other people's code. This week I got stuck real bad on a scrolling issue involving SB_THUMBTRACK notification messages and the SCROLLINFO::nPage member. I had to turn to Petzold once more and thank my lucky stars he was there! That scroll program shows the proper way to do it. I did this because I knew you would have never asked the question about globals if you had studied and understood my code.
Anyway, here is an easier program for you to figure out when you finally get your game working as good as you can such as it is. The scroll program I posted above is something I was working 'hot and heavy' on this week, so I posted it but scrolling is inherently complex and not a good place perhaps to attack the global issue. Here, however, is a very short simple Windows program that should succinctly as possible show how globals are eliminated by using some of the functions I previously described. Also, there are lots of comments in the code, and it uses the standard switch Window Procedure construct instead of my tricky message cracker routine. The program just creates a three dimensional box out of a class named CBox with length, width, and height members, and of course there is a CBox::Volume() member function. Can't get much simpler than that. However, the program shows the proper way to persist private data across invovations of the Window Procedure, and the proper way to draw to the Window using BeginPaint() and EndPaint() during a WM_PAINT handler with no improper GetDC() calls involved.
|
|
|
|
|
|
I might mention that sometimes you just have to bear down and study other people's code. This week I got stuck real bad on a scrolling issue involving SB_THUMBTRACK notification messages and the SCROLLINFO::nPage member. I had to turn to Petzold once more and thank my lucky stars he was there! That scroll program shows the proper way to do it. I did this because I knew you would have never asked the question about globals if you had studied and understood my code.
Last edited on
closed account (3pj6b7Xj)
Thanks freddie1, your awesome, I've printed the code out and will study it. Consider me your padawan learner. Now to study these, i've also printed out the first program and compiled...my simplest windows program compiled at 484kb while yours compiled at only 10kb, I was shocked! your program did more than mine and yet the resulting executable was incrediblly small, this was amazing to see...
closed account (3pj6b7Xj)
Ok I sat down and reviewed C++ pointers which I know about but just needed a refresher course, apparently I had some concepts wrong but i've got it all back now. I then studied the SetWindowLong() & GetWindowLong() functions in detail at MSDN and see what they do.
I see that you reserved 4 bytes of memory for cbWndExtra which is were you store the pointer, since the pointer is some type of special integer that holds addresses 4 bytes strikes a hint, anything smaller could probably cause a run time error depending how you use it.
First I notice you create a NULL pointer with the Cbox object class ...... CBox * Pbox=NULL; I also see that you have to always declare the null pointer on every part of the procedure, this made sense as the temporary null pointer is destroyed...where the magic really happened was when you wrote; pBox = new CBox(2.0,3.0,4.0); I know this will allocate memory for an object of type Cbox and store the address of that object in pBox the current temporary pointer which is now no longer NULL and pointing to an object. I do knwo for a fact that if you do not store the pointer address some where, when you return, you'll have a memory leak because you'll no longer be able to access the object since you lost the address! So you store it in the window extra bytes using window long ... SetWindowLong(hwnd,0,(long)pBox); ... I know the (long)pBox casts the value of pBox into a long since that is what SetWindowLong() expects, that effectively stores the address of the object in the window extra bytes...thats is simply genius...I smiled when I figured that part out! *rubbing hands* lol
So then on WM_PAINT, I see you create the null pointer again but now you use GetWindowLong to fetch the address and put it into the null pointer... pBox=(CBox*)GetWindowLong(hWnd,0); GetWindowLong(hWnd,0) gets the contents at the window extra bytes and I see you cast that into (CBox*) syntatic sugar that is some what confusing me but I know what is going on...I should return to pointers again and maybe re-read on casting or maybe some more casting.
It all makes sense now and you did everything through the windows procedure, after all, that is what the window procedure is for anyway. The WinMain was nothing special as it was just a simple winapi skeleton of a window frame and message pump which is quite attractive actually because you can store that code and just paste it in there when ever you want to use it.
pBox = (CBox*) GetWindowLong(hWnd,0); <--- I suppose (CBox*) is telling the compiler that you want the address of a CBox object? it was stored as a long so i'm assuming you are casting it back to type CBox the class object and the * indicates you want the address and not the object itself.
Then you can use pBox->m_dblHeight = what ever .... which looks very nice.
To add, on WM_DESTROY, I see you fetch the pointer again and call Delete to de-allocate the memory that was allocated for the object, good stuff. The way I saw the windows procedure, it looks like a C++ class in a rather strange way in that it has its own constructor WM_CREATE and its destructor WM_DESTROY, I see the hidden object-oriented programming you are talking about now :)
I will continue to re-read the code and see what else I can learn.
The way I see this, it looks like a genius windows exploit lol!
I see that you reserved 4 bytes of memory for cbWndExtra which is were you store the pointer, since the pointer is some type of special integer that holds addresses 4 bytes strikes a hint, anything smaller could probably cause a run time error depending how you use it.
First I notice you create a NULL pointer with the Cbox object class ...... CBox * Pbox=NULL; I also see that you have to always declare the null pointer on every part of the procedure, this made sense as the temporary null pointer is destroyed...where the magic really happened was when you wrote; pBox = new CBox(2.0,3.0,4.0); I know this will allocate memory for an object of type Cbox and store the address of that object in pBox the current temporary pointer which is now no longer NULL and pointing to an object. I do knwo for a fact that if you do not store the pointer address some where, when you return, you'll have a memory leak because you'll no longer be able to access the object since you lost the address! So you store it in the window extra bytes using window long ... SetWindowLong(hwnd,0,(long)pBox); ... I know the (long)pBox casts the value of pBox into a long since that is what SetWindowLong() expects, that effectively stores the address of the object in the window extra bytes...thats is simply genius...I smiled when I figured that part out! *rubbing hands* lol
So then on WM_PAINT, I see you create the null pointer again but now you use GetWindowLong to fetch the address and put it into the null pointer... pBox=(CBox*)GetWindowLong(hWnd,0); GetWindowLong(hWnd,0) gets the contents at the window extra bytes and I see you cast that into (CBox*) syntatic sugar that is some what confusing me but I know what is going on...I should return to pointers again and maybe re-read on casting or maybe some more casting.
It all makes sense now and you did everything through the windows procedure, after all, that is what the window procedure is for anyway. The WinMain was nothing special as it was just a simple winapi skeleton of a window frame and message pump which is quite attractive actually because you can store that code and just paste it in there when ever you want to use it.
pBox = (CBox*) GetWindowLong(hWnd,0); <--- I suppose (CBox*) is telling the compiler that you want the address of a CBox object? it was stored as a long so i'm assuming you are casting it back to type CBox the class object and the * indicates you want the address and not the object itself.
Then you can use pBox->m_dblHeight = what ever .... which looks very nice.
To add, on WM_DESTROY, I see you fetch the pointer again and call Delete to de-allocate the memory that was allocated for the object, good stuff. The way I saw the windows procedure, it looks like a C++ class in a rather strange way in that it has its own constructor WM_CREATE and its destructor WM_DESTROY, I see the hidden object-oriented programming you are talking about now :)
I will continue to re-read the code and see what else I can learn.
The way I see this, it looks like a genius windows exploit lol!
Last edited on
Just wait mrfaosfx! It keeps getting better!
You've got everything exactly right! Makes me proud! Are you beginning to see the full implications of this power?
C and C++ are phobic about ALWAYS knowing exactly what pointers are pointing to. You'll have to become familiar with casting and learn to live with it. When I put the (CBox*) in front of GetWindowLong() like this...
pBox=(CBox*)GetWindowLong(Wea->hWnd,0);
all I'm doing is making it possible for a function typed as returning a long to assign it to a pBox variable which was declared as being a pointer to a CBox. Without the cast the compiler will report that pBox is a CBox pointer - not a long.
When I declare pointers I always set them to NULL. The reason for this is safty. Usually memory allocation functions that fail put a NULL in the variable, but I hate to count on that. Its usually a good idea to test a pointer before you use it; especially if you have it stored somewhere. You'll use something like this...
if(pBox)
{
//whatever you want to do with it
}
else
//code for failure
It saves you from crashes!
Pointers are really, really important, and difficult to learn. One of the things that helped me with them is my full realization that they were conceptually really difficult, and that it would take my greatest effort and fullest concentration to completely master them.
You've got everything exactly right! Makes me proud! Are you beginning to see the full implications of this power?
C and C++ are phobic about ALWAYS knowing exactly what pointers are pointing to. You'll have to become familiar with casting and learn to live with it. When I put the (CBox*) in front of GetWindowLong() like this...
pBox=(CBox*)GetWindowLong(Wea->hWnd,0);
all I'm doing is making it possible for a function typed as returning a long to assign it to a pBox variable which was declared as being a pointer to a CBox. Without the cast the compiler will report that pBox is a CBox pointer - not a long.
When I declare pointers I always set them to NULL. The reason for this is safty. Usually memory allocation functions that fail put a NULL in the variable, but I hate to count on that. Its usually a good idea to test a pointer before you use it; especially if you have it stored somewhere. You'll use something like this...
if(pBox)
{
//whatever you want to do with it
}
else
//code for failure
It saves you from crashes!
Pointers are really, really important, and difficult to learn. One of the things that helped me with them is my full realization that they were conceptually really difficult, and that it would take my greatest effort and fullest concentration to completely master them.
Last edited on
Pages: 12