Jump to content

  • Log In with Google      Sign In   
  • Create Account


Whats cleaner? More global variables or getting Values thorugh functions?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 Agreon   Members   -  Reputation: 158

Like
0Likes
Like

Posted 15 August 2013 - 03:26 PM

Hey,

in my previous post i asked about my Input Manager. But then something came in my mind.

Instead of calling the "isKeyDown" function everytime, couldn´t i just set a global variable bool key[] and only change and check them?

Or when i want to get my mouse coordinates, do i call "getMousePositionX" or do i just create global variables "mouseX" and "mouseY"?

Whats cleaner?



Sponsor:

#2 ApochPiQ   Moderators   -  Reputation: 14622

Like
8Likes
Like

Posted 15 August 2013 - 03:42 PM

Global state is generally bad, and should be avoided wherever possible unless it causes extreme contortions to do so.

The problem with globals is that they tend to become very hard to keep track of; it's easy to fall into the trap of letting a dozen different places in code read and modify the global data, which then turns into massive headaches when (not if) you forget about one and it causes a bug.

Note that just avoiding global variables won't magically protect you from designing bad code, or code with similar problems as globals often pose - but it will encourage you to think about more appropriate ways to encapsulate responsibilities within your code.

#3 Agreon   Members   -  Reputation: 158

Like
0Likes
Like

Posted 15 August 2013 - 03:58 PM

Thank yout for your advice!



#4 dmatter   Crossbones+   -  Reputation: 3001

Like
2Likes
Like

Posted 15 August 2013 - 03:59 PM

Global state is generally to be discouraged for the reasons ApochPiQ mentioned, but you should also aim to encapsulate systems and their state using functions to provide a stable interface. It is not a big stretch to imagine that, at some point, you might have multiple threads and then you are reading and writing the key & mouse states from different threads; if that state was global you might quickly run into subtle concurrency bugs and race-conditions whereas if you had encapsulated it behind functions then you can implement a suitable locking strategy without affecting how the rest of the system interacts with the input-manager.



#5 Ravyne   Crossbones+   -  Reputation: 6908

Like
1Likes
Like

Posted 15 August 2013 - 04:02 PM

Also be aware that that this isn't a two-party system -- the options are not Globals on the left and Functions on the right. A perfectly-acceptable middle-ground might be to poll the input once per frame, hold it in a variable that's defined in a suitably-small scope, and then access that variable wherever keystate is needed. You might access that variable through its name alone, or as part of a class -- whichever you do, you might get ahold of it simply by being in a nested scope, or because it was passed into a function, or because a reference to it was passed into a class that contains that functionality. If you make reasonable choices, and organize your project well, such an approach need not introduce the same kinds of problems that honest-to-goodness global state does.

 

In general, you should prefer to pass information to functions or classes explicitly, rather than simply making it available implicitly. In this way you state which code is dependent upon which information (or which other code), which makes things easier to keep track off. Furthermore, if you later decide that a class or function really ought to depend on some other information (could just be a different source, it doesn't have to be a different kind of information) then you only have to update those places where the information (or functionality, if a class) is passed in, rather than every place where it's used.

 

This makes your code far easier to understand, reason about, and change. The code becomes less brittle and more robust.



#6 Pink Horror   Members   -  Reputation: 1115

Like
0Likes
Like

Posted 15 August 2013 - 05:38 PM

Hey,

in my previous post i asked about my Input Manager. But then something came in my mind.

Instead of calling the "isKeyDown" function everytime, couldn´t i just set a global variable bool key[] and only change and check them?

Or when i want to get my mouse coordinates, do i call "getMousePositionX" or do i just create global variables "mouseX" and "mouseY"?

Whats cleaner?

 

You could have a function in your Input Manager that gives you an array of bools as its result, or copies out an entire struct with that array, plus the mouse buttons and whatever else you need, if that's what you prefer to interact with.



#7 Norman Barrows   Crossbones+   -  Reputation: 1966

Like
0Likes
Like

Posted 15 August 2013 - 08:46 PM


Also be aware that that this isn't a two-party system -- the options are not Globals on the left and Functions on the right. A perfectly-acceptable middle-ground might be to poll the input once per frame, hold it in a variable that's defined in a suitably-small scope, and then access that variable wherever keystate is needed. You might access that variable through its name alone, or as part of a class -- whichever you do, you might get ahold of it simply by being in a nested scope, or because it was passed into a function, or because a reference to it was passed into a class that contains that functionality. If you make reasonable choices, and organize your project well, such an approach need not introduce the same kinds of problems that honest-to-goodness global state does.

 

i used to do something like this, get all key states all at once per frame (can't remember the windows call), stuff it into an array[256] of byte, then just check the values in the array as needed. the array was global in the low level keyboard input library. process_input and getstring were about the only things that used it.

 

now i just do:

 

if (Zkeypressed(VK_somecode)) blah_blah_blah();

 

where Zkeypressed calls the windows routine that uses VK codes: GetAsyncKeyState()

 

it really makes life easier. except for an input mapper, the keyboard input module is reduced to:

 

// returns 1 if vkey is pressed, else returns 0
int Zkeypressed(int vkey)
{
SHORT a;
a=GetAsyncKeyState(vkey);
if (a & 0x8000) return(1);
return(0);
}

Norm Barrows

Rockland Software Productions

"Building PC games since 1988"

 

rocklandsoftware.net

 


#8 Norman Barrows   Crossbones+   -  Reputation: 1966

Like
0Likes
Like

Posted 15 August 2013 - 08:53 PM

editor is screwing up.....

 

continued from last post

 

 

then you just call it as needed, where needed, when needed. No having to get and store key states. No scope or data hiding issues. windows is already doing those things. no hassles. nice, sweet, simple, and clean. just like you want writing code to be.  ; )


Norm Barrows

Rockland Software Productions

"Building PC games since 1988"

 

rocklandsoftware.net

 





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS