I feel really conflicted about Qt. On one hand, as a graphical toolkit/environment, it's great. It's well-structured and easy to use, and QML is basically everything web applications should have been.
On the other hand, as a C++ library it really couldn't be worse, with its flagrant reinvention of the standard library, pervasive UTF16, complex object hierarchies, raw pointers, extensive use of macros, etc., etc.
Maybe I'm just too choosy, but it'd be really nice to have a graphical toolkit that didn't have such an air of sausage factory to it.
I think that the reason for reimplementing stl functionality is that they want complex types such as QString as a part of their external interface and they want different minor versions to be binary compatible which can't be guaranteed for types like std::string unless everything is compiled with the same compiler and runtime. See https://qt-project.org/wiki/Dpointer
As for the raw pointer use you should always use QPointer smart pointers for objects whose lifetime you don't control. However they don't recommend passing QPointers as function parameters since they are easily/cheaply constructed and the reference count is embedded in the QObject instance itself in any case.
I really like the Qt syntax. It's well though out, readable, I can overlook it without years of study and it has a good documentation. I think it helps to not think about it as C++ at all, because it isn't really. It's a syntax subset of C++ with a few extensions and it's own standard library that happens to use a C++ compiler somewhere down the toolchain.
I don't see the issue with the object hierarchies either. You have your QObject and QWidget classes that are important and then all the stuff that builds on that. Not that complicated really once you get into it.
The UTF-16 thing is ugly, yea, but I did never see a practical issue with it.
Totally agree. After studying C++, I was wary of trying to use the language. It seemed to me that you'll get into trouble quickly and it requires years of experience to become an expert. I would rather use Qt because it insulates you from many of the pitfalls of C++. I especially like the slots and signals paradigm. I know there are libraries that do the same thing, but if you stay within the Qt framework, you'll be a lot more productive.
> On the other hand, as a C++ library it really couldn't be worse, with its flagrant reinvention of the standard library, pervasive UTF16, complex object hierarchies, raw pointers, extensive use of macros, etc., etc.
Have you given Qt a serious try? Most of the above arguments don't hold good at all.
* c++ std lib is total crap. Anyone arguing for it has no idea what a good API is. Have you used Qt container? It's as intuitive as it gets. The C++ std lib is performance optimized and most desktop apps don't need it. It comes at a cost of developers having to learn complex APIs.
* Complex object hierarchies - huh? Qt's value based types need no memory management. The pointer types has a simple parent-child relationship. Delete the parent and all children are deleted as well. How hard is this?
* Raw pointers - Commented truly like someone who hasn't understood Qt.
* Why do you care about UTF16? It's an internal representation. BTW, Do you write any web apps? Do you know or care what internal representation is used by strings? If you some ultra-special case of a performance critical app, no string library out there will be good for you. You will have to roll out your own.
Let me guess. It really looks like you are one on the few guys who likes writing libraries (as opposed to apps). People who write apps love Qt. People who like writing libraries don't like any other library other than their own because their way is the true way.
There are many valid criticism of Qt but these are none of them.
Calling the C++ standard library crap is acknowledging the Wheel was Not Invented Here.
Glazing over the fact that Qt has an incredibly complicated object hierarchy by saying "they're good for you" is not acknowledging the fact that it's complicated and difficult to learn or work with. You didn't even mention, e.g., MOC - Qt's incredibly complicated Meta-Object Compiler. And people call GObject complicated...
Ignoring the fact that basically every other platform than Windows (and the platforms it has managed to infect) uses UTF-8 as its One True Encoding, and that you and Qt are proliferating the claim that every sufficiently complicated C++ project has its own string class with its own specific peculiarities is not a good thing.
Most importantly, you can't dismiss his concerns by agreeing that all of them exist and that he shouldn't care.
Not sure how you concluded this is about NIH. Qt's container are very developer friendly and as an application author that's the first and most important thing that matters.
Saying moc is complicated is like saying dalvik or ART is complicated. These are just tools that work in the background. Just like you don't need to know ART internals, you don't need to know moc or the code it generates for you.
Arguing about string encoding is so 1990's, I won't comment.
No offence, but you calling the STL "total crap" can lend others to claim you haven't given the STL a serious try as well. A related stackexchange question on critisms of the STL [1]
That's b/c the C++ standard library (or its implementation among various compilers) was terrible 13 years ago when Qt 3 was released. Some say it still is.
Sorry, "fork" was the wrong term. How about "long-term working branch that might get merged eventually, but also might get used in preference to the original to the point that people start just submitting their PRs directly to it"? (Think egcs's "fork" of gcc.)
And by "Not everybody" you of course mean "People who don't know any better", right? The Qt legal situation has changed a lot lately, especially since Nokia went out of the picture. Look it up:
The situation is that a CLA is still required.
Personally, I don't care (I'm just a consumer who is not affected by the CLA). Others care and insulting them as "People who don't know any better" is not right.
On the other hand, as a C++ library it really couldn't be worse, with its flagrant reinvention of the standard library, pervasive UTF16, complex object hierarchies, raw pointers, extensive use of macros, etc., etc.
Maybe I'm just too choosy, but it'd be really nice to have a graphical toolkit that didn't have such an air of sausage factory to it.