Why are functions like exec() declared static in the QApplication class?

I am looking at qt-x11-opensource-src-4.3.0-snapshot-20070315\src\gui\kernel\qapplication.h and I find that at line 235 the exec() function has been declared static. So are many other functions like font(), palette() and even setFont(), setPalette() etc.

My understanding about static functions in C++ is that their only need is when a member function of a class can/needs to be called without an instance of that class, like for example the currentDateTime() function which is a member of the QDateTime class but can be called without an instance of that class. In fact, this function has no particular meaning when called upon an instance of that class since it does not create, access, modify or delete that instance in any way. So I can understand why currentDateTime() is a static member of QDateTime.

But I do not understand how exec(), font(), palette(), setFont(), setPalette() etc can be static when to my understanding these can be called only upon an instance of the QApplication class. Although for a Qt application there is only once instance of a QApplication class, the exec() and other functions are by definition dependent on this particular instance and have no meaning when separated from this instance. For example, setFont() can set the default application font only for the current application running and that means only an existing instance of QApplication. If there is no existing instance of QApplication, whose default font will setFont() modify?

Therefore I feel that it is meaningless to declare these functions as static. Please anyone confirm or disprove this hypothesis of mine. If my hypothesis is confirmed I can file a bug. Thank you.

Well, I would say the reason why it is done this way is because QApplication is a kind of "Singleton". At any point in time, there may not be more than one QApplication in a Qt application. (Which kind of makes sense :-)

Things like QApplication::setFont() and bretheren have an interesting meaning too if not QApplication is yet allocated; You could create a functions "setupDefaults()" that sets fonts/styles/pallettes and this kind of stuff, and be able to call it at any time. If for example no QApplication object exists yet, those settings will be stored away and used as soon as the next QApplication is instanciated.


In addition to those, you will find static accessors such as QApplication::focusWidget() those functions are nice to have as a static because they are usefull in places where it would be a hassle to ship a pointer to the current application to (and using qApp or QApplication::instance() everywhere just would look ugly. ;-) Besides the semantics for that call is always valid: if no QApplication instance is instanciated there simply is no focusWidget which means the function returns 0.


Now, this is probably not "by-the-book" object oriented design, but I would call it rather sensible. Mind you, QApplication is a very special case, so you will not find these design choices in too many places (and you should not of course) but here I think they make life just a little bit easier, so I am ok with it :-)



Have a nice day

Thanks for that reply. I guessed as much that QApplication being a only-one-instance-at-a-time class would be the reason. But really, though I can conceptually understand your idea of a setApplicationDefaults() function which sets defaults for an application which is going to be started, who is going to write such a function if he/she is not going to create a QApplication object later?

There is only the small convenience of not having to use qApp or "this" whenever you have to set or read the properties of a QApplication. But then, we have no choice about using "this" or QWidget * or whatever whenever we have to set or read the properties of another QObject. So it might well have been the same for QApplication. When we write so many "this"-es for those objects, what's with a few for a QApplication object?

Anyway, your explanation is valid and I accept it. If anyone else has any other interesting perspectives I (and I presume you too) would be glad to hear it of course.