Wednesday, March 24, 2010

Inner Qt

Lately I have played a lot with Qt. Generally it's nice and I think it's easy to adapt and get things done. Also the development of Qt have been blazingly fast, new features are implemented and it's going into good direction.

I have taken a closer look to the inner design of Qt. First note was that Qt is just one big collection of code. Of course it's divided into modules like QtCore, QtGui, QtNetwork, QtOpenGL, etc. But when you look the sources you'll see one big drawback: you really can't compile one module without compiling first almost all other modules. Also compiling only few classes or widgets is not possible.

The main reason for Qt being just a big pile of code is heavy usage of private members. In generally private members and classes are good. But somebody has led this into very wrong direction. Totally separated Qt classes uses each others private members/classes directly. That achieved by making the private members protected and listing other classes as friend classes. This leads to degeneration of the code. An extreme example is that QWidget, the very basic class in Qt. Let's see it's sources: qwidget.h. Total number of friend statements in qwidget.h is about 50. However not all of them are really used, but 50? Are you kidding? Then it hits me, what the heck does implementation of QPixmap::fill in qwidget.cpp ?

Another thing that does not fit in my mind is use of QApplicationPrivate. There's lot of use of it in qwidget.cpp. And I really don't get the point why? Why are these not public functions and members in QApplication or QCoreApplication? Of course there's some aspects which supports this kind of approach, but this was just an example. Such usages of private classes and members can be found all over the Qt. For example there's clean cases where private is used even if there's public member which does the same thing.

My point was that Qt is great, but could be even better if the inner design is reviewed and proper modifications made. I mean: using public members, avoiding usage of privates and friend classes and cleaning off all the stupidity. A good test could be: if you take a source files of a widget and compile it outside Qt source tree (compile with public API), does it compile without modifications? For most widgets and classes this should be true. Currently most of the classes fails this test. Of course using privates is ok when it's really needed. But I see no reason using privates so heavily as Qt currently uses.

1 comment:

Anonymous said...

Private classes are a design pattern to maintain binary compatibility easier and make the public interface look cleaner as you don't need to declare private members there. I have to admit I didn't look at your particular examples though.