"loose" variables...
Author
I have quite a few variables that store information about the state of my program and the image that is being displayed. These variables exist within the scope of my WinProc. I am thinking about encapsulating this information in a "ApplicationData" class. However, these vaiables are passed all over the place. Frames per second is important in my application and I am wondering if the overhead of accessor functions would be worth it.
How do you all approach encapsulating "loose" variables in your programs?
I'm confused... what's the difference between a "loose variable" as you're describing it, and a global variable? What are some examples of loose variables?
As for your question about accessor functions, accessor functions are generally inlined and have zero computational overhead (as long as they aren't actually computing things).
As for your question about accessor functions, accessor functions are generally inlined and have zero computational overhead (as long as they aren't actually computing things).
refactor your code till they are no longer necessary.
Quote:I am thinking about encapsulating this information in a "ApplicationData" class.why? what difference will it make if your gloabals are all wrapped up in a class they are still globals.
Quote:Original post by stonemetal
refactor your code till they are no longer necessary.
Erm, really? Can you give an example of how declaring hInstance as a global variable, for instance, would cause problems that would be solved by refactoring to remove the global?
Author
When I say loose, I just mean not part of any object. These variables are static variables in my WinProc (Win32) not global variables.
Quote:Original post by Noods
When I say loose, I just mean not part of any object.
I don't think you do. If you have a for-loop, with a variable int i used as the counter, do you consider i to be a "loose variable"?
Creating the main window is a standard approach used in every win32 application and it is in my oppinion comparable to the 'main' function in console apps. So I think you should identify the bare minimum needed to create the window, i.e. hinstance...
Then place all that into one .h file. Define entry functions such as Init, Update, Dispose and call them appropriately (passing parameters if needed). Then implement these functions in a separate .cpp file. From here on you should have no global variables, except perhaps one instantiation of a Main class.
Then place all that into one .h file. Define entry functions such as Init, Update, Dispose and call them appropriately (passing parameters if needed). Then implement these functions in a separate .cpp file. From here on you should have no global variables, except perhaps one instantiation of a Main class.
Author
Quote:Original post by SneftelQuote:Original post by Noods
When I say loose, I just mean not part of any object.
I don't think you do. If you have a for-loop, with a variable int i used as the counter, do you consider i to be a "loose variable"?
I have no globals. The reason I bring all this up is that I may end up moving to a state pattern and it might make sense to encapsulate this data so it will be easier to point to from my state objects.
Quote:Original post by Sneftel
Erm, really? Can you give an example of how declaring hInstance as a global variable, for instance, would cause problems that would be solved by refactoring to remove the global?
Yeah, really. It doesn't really matter if it causes problems or not, sloppy code is sloppy code. Globals show a lack of thought and discipline.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
