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.

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.

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);
}

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. ; )