While thinking about the input manager i am creating I began to wonder what the correct way of updating objects based up input was. Currently for any objects that need to be updated I simply add them all to a list of "process objects" and update them. However, with key detection happening at all times, how should I handle updating objects that move depended on input? For example, if I had a camera that moved when I pressed the "W" key, I would want that to process before the next time my list of "process objects" get updated, or is that a bad idea?

Most of the time, I like to take a "snapshot" of the input state at the start of the frame, and anything checking input goes by that. That way, you can check if a key was just pressed that frame, just released that frame, etc. and it's all consistent for everything. Also more portable, as you can use it on console systems by just checking the state of the keys at the start of the frame, and on event-based input systems like most computers, you have the events update the stored input state, and make a copy of it at the start of the frame.

Just-pressed/just-released events seen by the game are computed logically by examining the current frame's input snapshot versus the previous frame's snapshot, not by setting flags when processing keyup/keydown events or anything. Those are only used to update the current pressed/not pressed states that will be seen next frame. Much easier when the game code can check the up/down states rather than trigger states sometimes, and they all match up.

It doesn't play that well with jumpy frame rates though, like computers do sometimes. You can miss a press and release entirely during a long frame. If it's a problem, you could probably come up with some kind of buffering system, like if a keydown event happens, then make sure the key is seen as being pressed on the next frame regardless of whether it has actually been released before then. But make sure you keep the buffered state separate from the true state, so you don't end up with keys stuck down and such by ignoring the keyup events.

Well one of my main concerns if if the camera also have a physics object on it, for example, when it may be a third person camera.