Friday, June 7, 2013

Why I Don't Like Qt Open Source Projects (typically)

I'm porting a version of the QtCreator libraries from using qmake to premake4. Long long ago I did the same thing with QtCreator 2.5.0 and it turned my love for qmake into pure hatred. Before I had started that project I was firmly in the qmake camp because of it's simple syntax and portability with Qt projects. Then I started having to read other developer's pro files. Maybe I'll dig into qmake's more bizarre features after this blogpost; but what is really grinding my gears about Qt Open source projects right now is the private implementation mechanism they use.

Full disclaimer: private implementations are great. I love the pattern because it allows us to do lazy evaluation, fast swapping, binary compatibility, etc. It's a necessary implementation technique. With that being said, the way that Qt Open source projects do it is RIDICULOUS. Here's an example from the utils library from QtCreator:

#ifndef TIPS_H
#define TIPS_H

...

namespace Utils {
class TipContent;
}

#ifndef Q_MOC_RUN
namespace Utils {
namespace Internal {
#endif

class QTipLabel : public QLabel
{
    Q_OBJECT
...
};

#endif

Then inside of the cpp file:

#include "tips.h"
...

namespace Utils {
namespace Internal {

QTipLabel::QTipLabel() {
...
}

#include "moc_tips.cpp"

} // namespace Internal
} // namespace Utils

Okay, I've seen this pattern before with Qt projects where we will perform a moc-step and then include the resulting moc file at the bottom. I actually think it's a neat idea, most of the time the files have a .moc extension (meaning that the moc app was run on a cpp file). That's not the case here.

What this code is doing is running moc on tips.h, which will process QTipLabel. Because the namespace declarations for Utils and Internal are inside of Q_MOC_RUN, they are not going to be processed in the moc generated code. In other words, if you look at moc_tips.cpp there will be no mention of Utils/Internal. That allows us to nicely include it at the end of the cpp file.

Why go to this much trouble?! I understand wanting to be efficient and using the tools you have but don't twist the use of the tools (moc) to fit these really specific cases. Developers probably would say, "Well it works, so why care?" The reason you want to care and SHOULD care is that this is now the bar that new developers have to rise above to start contributing to your code base. It's code like this that kills projects and causes wasted time in understanding and refactoring. Just use something simple and consistent.

That's the end of my rant about Qt open source for today. Join my rant tomorrow when I continue to not take my meds...



No comments:

Post a Comment