Home

Qt

© 2007 Peter Thoemmes, 2007-04-26

Qt is enhancing the C++ programming language by the only thing C++ is really missing: a powerful portable graphical widget library. I found some wonderful statements about Qt in the foreword of Matthias Ettrich in the book 'C++ GUI Programming with Qt4' by Jasmin Blanchette and Mark Summerfield. He says that is is not just the single source compatibility, the feature richness, the C++ performance, the availability of source code and documentation. It is much more then this: the programmers like it and they do this because it 'feels right'. I fully agree! My opinion: whatever you do, if it doesn't 'feel' right, it isn't! Although, there is something which I personally don't like with Qt: the sick way of naming methods: 'funcName()'. I have seen many ways naming methods. The master himself 'Bjarne Stroustrup' sticks on the good old C style 'func_name()', which is ok for me. The SGI STL implementation does the same. Microsoft started 'FuncName()', which when used in the code of the same class has a great advantage. From the first moment you look at the code, you will see if function calls do call member functions or global C/C++/STL functions. That's my favorite, as I never saw a more meaningful way for naming methods. 'funcName()' anyway reminds of the coding style of the only really sick programming language/environment: 'Java'.

Our Qt setup is a very unique one. I don't use 'qmake' but only the 'moc' compiler and we use good old makefiles for all the platforms. I use the GNU MinGW C++ port to Microsoft's Windows and GNU g++, gdb and the Code::Blocks IDE everywhere. So I use only free and open source products and I don't use any Microsoft IDE or library. And so I have professional and slim source code without the special Microsoft nonsense inside. To make that run and work reliable was a lot of work and a big step in the beginning, but guarantees a painless day by day work now.

I only use the essential Qt libraries, meaning those which provide me the portable graphical library. All the rest I can do better then any third party library. My portable code is written without any compromise regarding performance and regarding 'it must feel right'. So I only include 'QtCore' and 'QtGui', and I only link '-lqtmain', '-lQtCore4' and '-lQtGui4'. I do link the Qt libraries statically to avoid that I suck from an upgrade of the dynamically loaded Qt libraries. It is clear that I can guarantee the fitness of my code only against the library I already used and tested. Nobody can guarantee the fitness of code against future libraries. That is the reason, why Java will always suck. A Java program is not reliable by definition, as it depends on the version of future virtual machines. Serious programmers developing software for automation and control or any kind of system that needs to run 24x7 will always use the C or C++ programming language. Anyway: there is enough abstraction layers on that level. First there is the Intel BIOS (or the Solaris Boot PROM or the Mac OS X EFI or Open Firmware). Then there is the operating system kernel and on top of that there is the operating system's user space with SDK and API. Never forget: before building more and more on top of the foundations, it is required to make the foundations stronger. And if you stop to work on the foundations because of cost reasons or because your programmers prefer to act lazy, you will pay the price one day in the future. Unfortunately not many people care for the future nowadays.

--------- Excursion:

For scripts run by a C or C++ application, like PHP scripts run by a web server's PHP interpreter or JavaScript run by a web client (web-browser) there is typically no final release date as there is no realistic way for testing all environments, because the amount of web-browser/platform combinations is incredibly high. On the other hand there is new techniques, file formats and streaming formats popping up every here and there and web-browsers need updates again and again (also for security reasons). So the web 'scripter' sees environment changes all the time and has no choice, but does as good as possible. Very often the web 'scripter' will face the day, when the scripts don't do the job anymore. That's fully ok here, as the only thing that counts is, that the web server and the web client (the C/C++ applications) are running stable at any time, because otherwise there will be no web script running at all. Still scripting is a powerful thing if the developer is not simply just a 'scripter', but having the background of a serious programming language like C or C++. If not, there is a high danger that he/she is writing James Dean code: "...denn sie wissen nicht, was sie tun" (German title of the film "Rebel Without a Cause" with the main actor James Dean. The German title means: "...because they don't know what they are doing"). BTW: there are many C or C++ programmers writing James Dean code as well. One needs at least 6 years of professional full time C++ programming to be able to handle most of the facets of the language and to understand the most important concepts and interfaces (socket programming, SQL and relational databases, multithreading, locking, kernel module APIs, ...). Good teams do have at least one experienced, highly motivated C or C++ programmer and one experienced, highly motivated system administrator with strong system security and networking background. All people in the team MUST have strong knowledge of the concepts of relational databases and all people in the team MUST have strong knowledge of the concepts behind TCP/IP networking. The most important thing still is that a developer is always in the search of beauty, when working on his code. The relation between the beauty of the things created and the truth behind those things is described in a wonderful way in the book 'Bionik' by Kurt G. Bluechel. Kurt gives examples of the work of many great minds (e.g. Albert Einstein) and says that there is two important relations, which can be described by mathematical functions f and g:

beauty = f(truth) truth = g(beauty)

Remark from my side: a programmer is never temporarily acting like this. Even his brain is wired like 'being in the search of beauty' or not. The reader will understand what I mean if he/she is on that 'path of the truth'. The style and beauty of a programmer's source code reflects the way his brain acts while solving software problems. Programmers excusing for their formatting and style by 'cleaning will be done later' are simply looking for a way to hide that they are not in the search of beauty. They will stop doing nice and clean code from the moment the responsible stops looking at their work. Such people have lifelong experience in hiding that unwanted 'feature', so 'pretending' is something they are really very good in. It is hard to divide the programmers of the 'Google generation' into 'pretenders' and 'makers', as Google and the Internet as such is the ideal tool to support and hide pretenders.

---------

Comming back to Qt. The basic design of my portable Qt client applications is of course layered and it looks like this:

Professional Hardwarenear Programming

Qt

© 2007 Peter Thoemmes, 2007-04-26