static mouse class

Skipping for a second that for some obscure reason I have 2 mouses connected to same box....

You're approaching the problem from the wrong end. You don't care much about the mouse. What you care are position and button events. So rather than starting with what a mouse is, start with what Input.

Your Input is what receives information from multiple sources. One is mouse-related, other keyboard, then there's joystick and various gamepads, etc.... Input is responsible for mapping arbitrary input to actions.

During construction, you hook API as needed to receive callbacks/messages/events/... from an arbitrary set of HIDs.

Which brings us to original point - why would you care about the mouse? Both on notebook (the pad and USB mouse) as well as on desktop (2 USB mice) no application has even the slightest problem if I switch between the two. The input into your application is already static in context (applications deal with cursor and mouse clicks, not mice), and there is no real need to deal with input devices on individual basis. Even worse, if you ever do choose to provide it, not only is there not just a single mouse, there's a whole set of other HIDs.

Input is abstraction of all input that feeds the Controller which in turn controls some part of scene. That's all the abstraction you need.

The above abstraction lends itself well to current experiments with multiple inputs (such as those touch screen desks people control with hands). In that case, you simply create as many Inputs as needed, and wire them to multiple controllers. Right now, assuming that there can only be a single Input or single Mouse is very flawed assumption. In long term, you might also not need Controller to be local, they might receive data over network, or from two input devices, or similar.

Quote:

i am stuck with the question of can the other objects inherit from it

Static instances and inheritance are problematic at best, and probably conceptually impossible if they are stateful.

i think we are talking about 2 different things. im not using 2 mice or 2 keyboards. i want to have a mouse object that multiple objects can access through inheritance or as an object inside the class.

say for example im building a game. in the game i have to use the mouse for movement, whether i want FPS movement, and then switch to 3rd person. i also have to use the mouse for menus and GUI items too. in my program im going to have many functions that will use the mouse's data. i have a function that will process the camera's movement, which is in the camera class. ill have a function that will do projections and unprojections on the scene, which are global. i may change them after a while. i also have a function that captures buttons for the player. i want to create a class that contains the mouse's data and every class can use. is this not advisable? is there an easier way to do this?

Conventional terminology is Controller. It defines the interface which controls in-world objects.

Controller could be move_forward, jump, change_camera, shoot. Or it could be higher or lower level, depends. Lowest would be simply literal mouse inputs as coordinates. But Controller is not necessarily 1-1 mapping to mouse or keyboard. It usually defines actions that can be performed in scope of user in-world content.

One way to do it is to make Controller a virtual class, and then extend it for various input devices, such as MouseController. Problem here is, as outlined above, there's a lot of controllers, and typical inheritance fails. At minimum you'd need MouseKeyboardController class. And the whole approach is also reversed - actions are actually constant, who calls them changes.

As such it makes sense to define some external class which does nothing but feed the controller, let's say Input. This class has no real functionality on its own except for start/stop/configure/set_controller, since it's event driven.

In the end, things look like this:

MouseInput ----+                       +--> CameraKeyboardInput -+--> PlayerController --+--> MenuGamepadInput --+                       +--> Character                    AIController ------+--> NPC                                       +--> NPCNetworkInput ------ RemoteController -----> RemotePlayer                                       ...

Inputs extend Input interface.
Controllers extends Controller interface.

The advantages of this design become clearer once you consider that various parts can be recombined to serve other functionality. Then, you just re-attack Controllers or Inputs as needed.

In networked game, GM, some spell effect can use different Controller to take control of player's character.
During cinematics, ScriptedController takes control of player's character.
When you interact with some menu, player's controller is simply told to control that instead of character.

How you pass information between these is your own choice. You can push data, so that Inputs call Controller, which in turn calls the entity it controls.
You can use poll model, so that on every tick, Entity polls if controller wants something, and controller polls if Input has some new data.

As always, YMMV.