3 ms·

Raymond Chen in his excellent The Old New Thing blog frequently asks - "What if two programs did this". What if every large C++ library came with their own cus

Raymond Chen in his excellent The Old New Thing blog frequently asks - "What if two programs did this". What if every large C++ library came with their own custom preprocessor? The major issue with moc is that it is evidence that Qt does not think of itself as just another C++ library that you can plug in to your code, but that it tries to be the programming environment and the fact that it uses C++ is just an implementation detail. Moc is only the most visible of the symptom of the underlying philosophy. It is also evidenced in the QCollections and by such things as QThread which duplicate much of the C++11 functionality. When I evaluate a library for my project, I want it to think of itself as "just another C++ library", not "The Framework that you base everything in your application around". Qt is a great illustration of Joe Armstrong's quote "You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

blub 10y ago
Qt is a framework, not a library. Frameworks usually expect apps to conform to their particular way of doing things. If one wants to use Qt as a library, I think one can ignore the moc now that lambdas can be used as slots in a signal-slot relationship. Now that the standard C++ lib is high quality on most platforms, one could also ignore the threads/containers.
pzone 10y ago
If I want to write a cross-platform GUI application supporting a single introspection, threading model and signals/slots mechanism for all members, then I'm asking for a jungle, not a banana. What parts of Qt would one want to split out and use separately? C++ stdlib collections not thread safe by default and cannot be used as drop-in replacements for Qt's collections. Qt's collections are designed specifically to work nicely inside its general framework, but would come at a speed cost used naively in some other sort of project. Also keep in mind that Qt is much older than C++11 and is just now switching to the standard library for its backend where possible. You can still use a non-c++11 compliant compiler with Qt 5.6 and utilize QThreads. It reminds me of the argument that systemd is problematic because it's too big and complex. Well, sometimes it makes sense to write a complex system for the sake of ensuring that many complex components interoperate with ease, and system-wide changes can be coordinated between the libraries.
- vetinari 10y ago
  > What parts of Qt would one want to split out and use separately? That's the wrong question. The right question is: what are you going to do, when you need to use 2-3-4-5 libraries and each one of them insist on using it's own primitives, collections, object hierarchies, etc. Are you going to spend your youth just writing shims to marshall data among them?
  - msbarnett 10y ago
    Is that a problem that anyone shipping products built with Qt is actually running into, though? Yeah, it's a GUI App Framework, not a GUI library. Yeah, it would be hard for 2-3-4-5 App Frameworks to co-exist. But how often would that ever come up? Frameworks, unlike libraries, aren't intended to be mix-and-match. Complaining about that is like complaining that water is wet.
  - to3m 10y ago
    I don't know how much C++ you've done, but your "Ahah! BUT WHAT ABOUT" scenario sounds exactly like virtually every C++ project I've worked on. You have N libraries, and each library has its own string class and templated array class, all with different member function names. The answer to your question is: yes. Usually you're going to do some transformation or processing when moving from one type to the other, so you just fold the conversion into that. It's stupid and you roll your eyes and you just kind of carry on.
    - vetinari 10y ago
      > scenario sounds exactly like virtually every C++ project I've worked on That's exactly the point :). It is not only C++, but also C problem. Maybe I've grown coddled with Java, Python and a few other languages, where the third party libraries do agree on the types they use.
- netheril96 10y ago
  > C++ stdlib collections not thread safe by default and cannot be used as drop-in replacements for Qt's collections. I agree with other parts of your post, but not this. How is Qt's collections thread safe in any way? And won't that be a huge performance cost, since most of the time, collections do not need to be thread safe?
nocman 10y ago
"...which duplicate much of the C++11 functionality." In all fairness to Qt, the original version of the library predates the ISO approval of C++11 by 16 years! Much of the functionality the library provides was not even close to being available in the c++ standard libraries for many of the years since it was first released. I understand if Qt is not your cup of tea, but many successful applications have been written with it, and a lot of that is due to the breadth of functionality the library provides (and in a cross-platform way). It's a tool like anything else, and I don't think it deserves to be dismissed out-of-hand.
- dkersten 10y ago
  I vaguely remember that Qt built their containers because at the time STL was young and not very well supported.

blub 10y ago

Qt is a framework, not a library. Frameworks usually expect apps to conform to their particular way of doing things. If one wants to use Qt as a library, I think one can ignore the moc now that lambdas can be used as slots in a signal-slot relationship. Now that the standard C++ lib is high quality on most platforms, one could also ignore the threads/containers.

pzone 10y ago

If I want to write a cross-platform GUI application supporting a single introspection, threading model and signals/slots mechanism for all members, then I'm asking for a jungle, not a banana. What parts of Qt would one want to split out and use separately? C++ stdlib collections not thread safe by default and cannot be used as drop-in replacements for Qt's collections. Qt's collections are designed specifically to work nicely inside its general framework, but would come at a speed cost used naively in some other sort of project. Also keep in mind that Qt is much older than C++11 and is just now switching to the standard library for its backend where possible. You can still use a non-c++11 compliant compiler with Qt 5.6 and utilize QThreads. It reminds me of the argument that systemd is problematic because it's too big and complex. Well, sometimes it makes sense to write a complex system for the sake of ensuring that many complex components interoperate with ease, and system-wide changes can be coordinated between the libraries.

vetinari 10y ago
> What parts of Qt would one want to split out and use separately? That's the wrong question. The right question is: what are you going to do, when you need to use 2-3-4-5 libraries and each one of them insist on using it's own primitives, collections, object hierarchies, etc. Are you going to spend your youth just writing shims to marshall data among them?
- msbarnett 10y ago
  Is that a problem that anyone shipping products built with Qt is actually running into, though? Yeah, it's a GUI App Framework, not a GUI library. Yeah, it would be hard for 2-3-4-5 App Frameworks to co-exist. But how often would that ever come up? Frameworks, unlike libraries, aren't intended to be mix-and-match. Complaining about that is like complaining that water is wet.
- to3m 10y ago
  I don't know how much C++ you've done, but your "Ahah! BUT WHAT ABOUT" scenario sounds exactly like virtually every C++ project I've worked on. You have N libraries, and each library has its own string class and templated array class, all with different member function names. The answer to your question is: yes. Usually you're going to do some transformation or processing when moving from one type to the other, so you just fold the conversion into that. It's stupid and you roll your eyes and you just kind of carry on.
  - vetinari 10y ago
    > scenario sounds exactly like virtually every C++ project I've worked on That's exactly the point :). It is not only C++, but also C problem. Maybe I've grown coddled with Java, Python and a few other languages, where the third party libraries do agree on the types they use.
netheril96 10y ago
> C++ stdlib collections not thread safe by default and cannot be used as drop-in replacements for Qt's collections. I agree with other parts of your post, but not this. How is Qt's collections thread safe in any way? And won't that be a huge performance cost, since most of the time, collections do not need to be thread safe?

nocman 10y ago

"...which duplicate much of the C++11 functionality." In all fairness to Qt, the original version of the library predates the ISO approval of C++11 by 16 years! Much of the functionality the library provides was not even close to being available in the c++ standard libraries for many of the years since it was first released. I understand if Qt is not your cup of tea, but many successful applications have been written with it, and a lot of that is due to the breadth of functionality the library provides (and in a cross-platform way). It's a tool like anything else, and I don't think it deserves to be dismissed out-of-hand.

dkersten 10y ago
I vaguely remember that Qt built their containers because at the time STL was young and not very well supported.