I think Im going to use it with C++ and OpenGL. I hope it has no effect on performance
It has a big effect on performance, actually (if using the Widget system). These kind of APIs are designed for regular non-game applications, and the whole way the API is laid out goes contrary to the whole way most games are laid out. Games have infinite loops of: handle events, update, draw as fast as you can. Applications have infinite loops of: react to events, with the events sometimes telling the GUI to redraw itself.
Games are designed to run as fast as possible, with thousands and millions of objects needing constant updating, where applications are designed to sleep as much as possible, and only updating one or two objects when they are interacted with.
You can still make games with Qt and OpenGL, you just need to be aware of the performance effects. If you're making something simple, you probably won't notice any slowdown (though you'll notice the extreme difference in architecture), but once you start having more performance-critical requirements, you might bump against it. It's unfortunate, because Qt would otherwise be very useful for game GUIs (since you use CSS to skin the widgets). One of these days someone needs to modify Qt and make a version that is game-friendly. ([Edit:] Apparently some people are: Qt Game Enabler and Qt Game API - but I'm not sure how stable and active they are)
My game, which is a simple 2D game, using Qt for the editor but SFML for the game. I hope to get it so I can compile Qt entirely out of the code (and only use SFML) for when releasing the game, and only use Qt in the version of the game with the built-in editor.
Note, I'm not saying Qt is bad. It's an excellent API. It's just not designed with games in mind, and if you want to use it for games you need to be aware of the shortcomings and decide whether the pros are worth the cons, or how to work around those shortcomings (I believe they can be worked around, but it'll take some work).