reducing global variables in windows programs

I'm fairly new to Win32 + MFC but it seems to me that using globals is virtually unavoidable.. with the WinProc and all.. or in MFC with different classes. Is there a solution to this problem I haven't come across yet in my learning? I never use global variables in my other programs, but it seems they must have to play a major part in Win32 or MFC programs.

In the wnd procs, just declare then static...they will then be there on the next call

In MFC, declare your simple variables in in the class declaration.....they will stay in scope as long as the class

If you want to access something in another class with MFC, there is a dirty way of using AfxGetApp () to get a pointer to your app....you might be able to access other classes through that depending on how you have built it......I dont like doing this much though

Quote:

---

I'm fairly new to Win32 + MFC but it seems to me that using globals is virtually unavoidable.. with the WinProc and all.. or in MFC with different classes. Is there a solution to this problem I haven't come across yet in my learning? I never use global variables in my other programs, but it seems they must have to play a major part in Win32 or MFC programs.

---

Mmm, I know how you feel. When I started programming with the Win32 API, I was disgusted. Global variables, static variables... petzolds book is purely C. It scared me. I haven't touched it in awhile... I'm looking for a book, or a refrence which deals with the Win32 API and Object Oriented concepts (Basically a book that teaches the Win32 API with C++)

Where can one find petzold's book?

Quote:

---

Where can one find petzold's book?

---

Try Amazon.com or order from a ask your local bookstore for the phone numbers of sellers of "hard-to-find" books. I used to work at a bookstore and we had lists of suppliers.

Quote:

---

I'm fairly new to Win32 + MFC but it seems to me that using globals is virtually unavoidable..

---

You too? :p

Yeah MS really made a mess of their API, an accident, I'm sure ;)

Y'know, here I am, been programming for a year now, and at least 6 mos of that messing with Win32. What an occultish ritual THAT is! For one, there is little *solid* documentation of how functions are implemented, how they affect other areas of your app, etc. Worse yet, functions do not work as expected at times, as in: parameters that SHOULD be non-zero to work unexpectedly do, or vice versa! In fact, I just deleted my entire C Windows library. Too buggy. So I am rewriting it from scratch in - guess what? - C++ !!
So that would be my first suggestion. Second, work slowly, mastering each little piece till you have a stable framework.

I don't know if this will help but here are some previous cprog->windows discussions:

http://www.cprogramming.com/cboard/s...static+wndproc

http://www.cprogramming.com/cboard/s...hlight=wndproc

guys, I'm a windows developer and there are only three types of globals I EVER have in my code.

WinMain() obviously

WndProcs() because that's our messages

and any Exported DLL functions. usually I only have one in my dll's to give me access to an object.

The deal is this...

1. Create an instance of your "Window" object in WinMain
2. Call CreateWindow() width an LPARAM of the pointer to the object
3. Handle WM_CREATE in the WndProc such that it does a SetWindowLong(hWnd, GWL_USERDATA, lParam); (of course the lParam means the item out of the CREATESTRUCT) This is your object
4. Each time into the callback, GetWindowLong(hWnd,GWL_USERDATA) to get the object pointer.

It's very simple, this provides a way of having NO GLOBAL DATA which is the way it should be.

I realize that you may not want to use classes also. My method works just fine for structs also. Put all data associated with that window in a struct and pass the pointer into createwindow as above

But - Why so against global varibles?

Quote:

---

Originally posted by Hershlag

It's very simple, this provides a way of having NO GLOBAL DATA which is the way it should be. [/B]

---

Sounds fascist.

Quote:

---

3. ...
SetWindowLong(hWnd, GWL_USERDATA, lParam);

---

and ugly.

Global data is widely regarded as sloppy. I don't see that as something that makes me fascist. :rolleyes: A neat freak maybe but hardly fascist. Besides, any windows programmer should write code that is fairly thread-safe and globals are the anti-thread.

How is SetWindowLong ugly? it's a great way to associate data with a window in Win32. You have SetProp() also, but it requires a string search and is probably a bad alternative.

Thanks for all the help, I now see several solutions to this problem, and I also am glad to realize I'm not the only one faced with this issue.


But - Why so against global varibles?


Of course this comes from a man w/ the ID of VBProgrammer :P.. Here in C++ world they are generally regarded to be on the evil side. (no offense, the VB thing was just funny to me)

coz, you don't need to baby VB. He works with asm and is even writing his own OS.

ah ok, guess I just didn't expect that from the nick :)

I work with a guy that is probably much like VBProgrammer. We used to debate things like global variables until we realized something about programming. There are different levels of abstraction that programmers work in. Basically, the lower level coder you are, the more often you are reinventing the wheel. The world NEEDS people who are willing to reinvent the wheel so that we can come up with better and better wheels. But it also needs people at higher levels of abstraction to build things with those wheels.

The higher level of abstraction you work in, the more you should think about structure and design being readable. The lower you work in, the more you need to think about optimization for speed. Global variables are suitable to this low level but not higher levels. VBProgrammer has an ironic name in that he obviously thinks in this low level but you should understand that without us higher level thinkers we'd have great wheels but CRAPPY SOFTWARE!

God, i've got this fussy feeling all over me...

Just to point out (yeah, i see your point about having debates about these type of things) that to use SetWindowLong(hWnd, GWL_USERDATA, lParam) which is an API call your computer must use a far pointer to a call gate which isn't particularly fast. Not something you should worry about too much, however for a global value which changes very often you should definatly use a global varrible. Obviosly storing things like the window handle wouldn't be affected by this.

Yeah and i know i should change my name but that would confuse everyone on Flashdaddee...

Quote:

---

that to use SetWindowLong(hWnd, GWL_USERDATA, lParam) which is an API call your computer must use a far pointer to a call gate which isn't particularly fast.

---

aren't all pointers in Win32 FAR? actually, isn't FAR defined as nothing now? I know it meant a lot in Win16 so I'm not trying to show my brilliance here.

Quote:

---

for a global value which changes very often you should definatly use a global varrible

---

if you are multithreaded this will kill your program. I had to explain this to my co-worker who is an ancient Win16 guy. He had this wonderful way of using a global char string for EVERYTHING that he needed a string for. Great in the old days but with two threads using the same string for two different purposes? WOOooohhh Das bad!

Hershlag's right. Globals may be o.k. for single-threaded apps (if not sloppy), but for multithreaded they could spell doom for yer program. Even if you resorted to a critical-section, that would mean defining yet another global variable (unless you used a Win32 mutex/semaphore, of course)!

Quote:

---

Originally posted by Hershlag

aren't all pointers in Win32 FAR? actually, isn't FAR defined as nothing now? I know it meant a lot in Win16 so I'm not trying to show my brilliance here.

---

Yup...all windows pointers are 32bit addresses......that's all that's needed as windows processes sit in a flat address space

In 1 header I saw FAR defined as

#define FAR

so it doesnt do much :)

  VBprogrammer, am I right in thinking that the "VB" in your name stands for "Very Bad", and not "Visual Basic"? I just seem to recall you telling me that at some point.

  Oh, by the way, I can identify with both the weel-reinventors and the cart-makers! I go through programming "moods". Sometimes I prefer ASM, sometimes I prefer C/C++. It also depends a lot on the project I happen to be working on at the time. I tend to use ASM whenever I feel that it would significantly increase the speed.

Yeah, Sorry i got my MMURTL and Windows wires crossed up (in MMURTL the OS is in a different segment to the user code which means FAR pointers are required). I plead temporary insanity.

However you might want to chew on the fact that with only one processor only one task can be exicuting at a time, therefore sencible use of global varribles should not be a problem. What you are talking about is code re-entracy where if a thread is updating something critical (i.e. a linked list) then the other process comes along and tries use the same thing it would cause big problems. There have to be measures taken to prevent problems like this occuring. In windows this takes the form of custom (WM_USER based) messages.

Compuboy:: shhh! That depends on how stupid my previous comments have been...

Oh yeah, just remember without us low-levelers you high levelers wouldn't have a leg to stand on! ;)

Quote:

---

Originally posted by VBprogrammer
However you might want to chew on the fact that with only one processor only one task can be exicuting at a time, therefore sencible use of global varribles should not be a problem. What you are talking about is code re-entracy where if a thread is updating something critical (i.e. a linked list) then the other process comes along and tries use the same thing it would cause big problems. There have to be measures taken to prevent problems like this occuring. In windows this takes the form of custom (WM_USER based) messages.

---

No there are definately problems when you have more than 1 thread accessing global data...and it has nothing to do with messages....windows offers no guarantee that a piece of code will execute fully without being pre-empted by another thread.....its true that 1 processor can only run 1 thread at a time, but the allocation of clock cycles does not run how you would logically expect and you cant simply rely on it.

Windows offers various messures for you to guard global data...for instance the CRITICAL_SECTION..Used properly this will give a guarantee that 1 thread will complete a task with reagrd to global data before being pre-empted...for more info, look up Jeff Richter's book - he gives a whole chapter to thread syncronisation.....

Yeah I know what pre-emptive multitasking is Fordy. :)

My favorite programming phrase. "Global is evil"

the thing about critical sections is they should be used sparingly. They switch you back to sort of a procedural mode and there's no point in being multithreaded!

Quote:

---

the thing about critical sections is they should be used sparingly. They switch you back to sort of a procedural mode and there's no point in being multithreaded!

---

:confused:

Yes, there is! Threads make a program run smoother, and allow you to do what just isn't possible otherwise. Also, it is simple to create a class that encapsulates all of the the "procedural" stuff, critical sections and all...

Can I take this opportunity to ask about static variables please?

I am creating my first WinAPI program in the form of a game of battleships. I have created a grid of square bitmaps and I wish the user to click on the square he/she wishes to fire at and then click a button to fire. When the user clicks on the square, the WM_LBUTTONDOWN message is handled and the coordinates of the cursor position are stored in a globally defined integer for use by WndProc() once the user clicks the "Fire" button. If this integer were declared inside WndProc() as a static integer would it have the same effect (i.e. contain the data given to it during the last WndProc() call)? What about if (as I often do) I initialise the integer to 0 at the beginning of WndProc()? Will it revert to 0 every time WndProc() is called?

Thanks

Quote:

---

Originally posted by Sebastiani
:confused:

Yes, there is! Threads make a program run smoother, and allow you to do what just isn't possible otherwise. Also, it is simple to create a class that encapsulates all of the the "procedural" stuff, critical sections and all...

---

I think you missed my point. "Sparingly" doesn't mean not at all. For the time you are in a critical section you are not multithreaded. That's what I meant. Overuse of them will eliminate the multi-threadedness of your app. das all

Quote:

---

Originally posted by minesweeper
Can I take this opportunity to ask about static variables please?

I am creating my first WinAPI program in the form of a game of battleships. I have created a grid of square bitmaps and I wish the user to click on the square he/she wishes to fire at and then click a button to fire. When the user clicks on the square, the WM_LBUTTONDOWN message is handled and the coordinates of the cursor position are stored in a globally defined integer for use by WndProc() once the user clicks the "Fire" button. If this integer were declared inside WndProc() as a static integer would it have the same effect (i.e. contain the data given to it during the last WndProc() call)? What about if (as I often do) I initialise the integer to 0 at the beginning of WndProc()? Will it revert to 0 every time WndProc() is called?

Thanks

---

I think you are referring to the initialization of the static as in:

Code:

---

static int coord_x = 0;
static int coord_y = 0;

---

and the answer is nope. Only when the program first starts. Static in this case is much like a global in that it exists for the length of the program. The initialization does not happen every time in.

Quote:

---

I think you missed my point. "Sparingly" doesn't mean not at all. For the time you are in a critical section you are not multithreaded.

---

Ok. I don't mean to be nitpicky but I just want to add that critical sections do not affect the multithreadedness of an app. Well, ok, I think I see your point now. In a sense they DO put the threads that require the same data into a sort of "procedural" processsion...Nevermind :) Anyway, in a lot of cases, separate threads interact very little. That's all. I'll shaddup now :D

Sebastiani, at least YOU understand threads and their importance to windows. That's more than I can say for SOME V(ery)B(ad)Programmers. Just kidding VB:D

OK, i'll admit it, i haven't done that much windows programming. But i do know how the intel processors implement multitasking, segmentation, paging and all sorts of other useless stuff... :P

we love you anyway.:p

Gosh, thanks Hershlag! ;)

BTW, i'm thinking of visiting Florida (FL is Florida right?) some time in the first few months of next year. Should be fun.

cool. Disney World I take it. In my former life I drove monorails there. kinda fun.

We might visit Disney, its really expencive though. I might get a few flying lessons instead, much more fun. You know Florida residents get tickets for a third of the price, way no fair!

the discounts aren't year round and pretty much never 1/3 rd but I know what you mean :). Besides, I used to have a bunch of free passes from when I worked there. All gone now unfortunately. Cape Canaveral is interesting if you want something inexpensive to do. That is if you have any interest in space travel. Plus there are lots of beaches if you're into that sort of thing.

A bit off topic now huh?:D

Yeah, alot off-topic but WTH. I've been to Cape Canaveral its pretty cool. I want to go to Bush Gardens this time, i would also like to visit Sea World and Universal but other than that im not too bothered.

if only one park, Islands of Adventure at Universal is a must. bunch-o-coasters.

Thanks for the advice Hershlag, ill keep that in mind.