6 ms·

I want to like Qt but I hate that it needs moc. Also I don't like that it doesn't use much of the STL - it forces you to use classes like "QVector" and "QList"

I want to like Qt but I hate that it needs moc. Also I don't like that it doesn't use much of the STL - it forces you to use classes like "QVector" and "QList" instead of std::vector and std::list.

lossolo 10y ago
You can use std as much as you want. Qt doesn't force you to use their containers. Moc is not a problem anymore also, it's more an a myth now than anything else.
- jlarocco 10y ago
  That may be technically true, but programs using the std containers have to convert at some point if the data has to show up in the GUI. There may be some really clever ways to avoid a bunch of copying and string conversions, but by default there will be a bit of overhead converting back and forth. I'm not sure what you mean by "Moc is not a problem anymore, ...". AFAICT, Moc is still used by Qt and is at least still in their documentation. http://doc.qt.io/qt-5/why-moc.html http://doc.qt.io/qt-5/why-moc.html I'm personally not too bothered by Moc and see it as a trade off of using Qt. I'd prefer a cleaner "pure" C++ solution, but I don't know of any GUI toolkits as nice as Qt without Moc. Qt is still my preferred GUI framework, and I use it from C++, Python, and lately Common Lisp. My biggest complaints are the way it's been increasingly tied to Qt Creator and the focus on Qt Quick and QML.
RotsiserMho 10y ago
I avoided Qt for a long time due to what I'd heard about moc being required. However recent versions support connecting lambdas to slots which is sufficient for my relatively simple application to avoid using moc to set up signals/slots.
- symlinkk 10y ago
  Do you have a link that shows how to compile a Qt app without moc? I looked specifically for this and could only find this, which is unofficial and contains a bunch of ugly macros: https://woboq.com/blog/verdigris-qt-without-moc.html https://woboq.com/blog/verdigris-qt-without-moc.html
  - carewolf 10y ago
    Just don't use slots.
- defiancedigital 10y ago
  You should consider that c++ lambdas does not offer the same level of connection that signal/slot does (direct,queue,blocking,unique) ...
  - RotsiserMho 10y ago
    True, but a lot of that functionality can be gained using boost::signals2 and a simple cross-thread queue. (though some may question the wisdom of trading one dependency for another, I prefer my dependencies decoupled from each other). Still, as I said, lambdas are enough for my simple application.
zanny 10y ago
Theres a neat project in the works: https://github.com/woboq/verdigris https://github.com/woboq/verdigris Unlike Copperspice, the other MOC-less Qt, this one is API compatible with Qt itself, you just include it and drop the MOC and use its functions instead of the original library ones and it can connect to normal Qt data structures. And like others have said, you can use as few or as many Qt data structures as you want. The problem is that if you end up using Qt IO, you end up getting QStrings and QVariants, which you usually want to keep that way and end up using containers that recognize those types. If we had a good C++ var type, and a usable string class, there would be an argument to depreciate whats there, but even Qt cannot do utf-8 right (QString is utf-16).
- VeejayRampay 10y ago
  For those interested in such things, verdigris comes from the French "vert de gris", which is the colloquial name for copper oxide (translates to green of grey or grey's green).
coldtea 10y ago
>Also I don't like that it doesn't use much of the STL - it forces you to use classes like "QVector" and "QList" Which are quite better designed, more lightweight and better suited to the GUI tasks -- not to mention take less time to compile when used. Of course if you want you can also use STL.
dkersten 10y ago
Serious question because I'm curious: what is the problem with the MOC? Sure, its another build step, but so what? I mean, most large complex software has numerous build steps and MOC is pretty straightforward (and if you use QMake or QtCreator, its pretty much invisible to the programmer). I'm trying to understand why people dislike it so much.
- RotsiserMho 10y ago
  My problem with it is the fact that it inserts itself in my otherwise standard-conformant C++ code; right in the middle of class declarations. If I decide I want to use another GUI framework I'd have to refactor that code. Most other build steps occur before or after compilation and are far less intrusive. In short, it's too tightly-coupled to application code.
  - dkersten 10y ago
    You mean stuff like the "signal" and "slot" declarations in the class definition? Wouldn't these types of classes be tied to the GUI framework anyway due to the inherited classes, implemented virtual functions, widget classes referenced and so forth? In my experience (having used Qt, GTK, FOX, FLTK and wxWidgets over the years), different GUI frameworks are significantly different in their APIs and how they work, to the point where I think changing existing code from any of these to any other is a very difficult job, with or without moc.
  - joezydeco 10y ago
    If I decide I want to use another GUI framework I'd have to refactor that code. If you're already developing in Qt, what do you think the probability of that is? Personally MOC is worth the price of admission just to have signals transparently marshaled and queued across threads. It makes life incredibly easy.
- Too 10y ago
  It pretends to be c++ but it doesn't support all features and it fails silently during compile time when you don't use it in the exact specific way, problems first arrive at runtime. Some examples of seemingly simple things that just dont work without wrestling or not at all: Objects referring to other types of objects, enum class, 'using' aliases, stdint types, namespaces. Signal slot connections are not compile time type safe. The make process is also broken as sometimes it doesn't understand which files should be rebuilt so you have to force it by removing all generated files.
fisherjeff 10y ago
I actually find their container classes to be much more usable than the STL containers. Obviously that locks you in to Qt, but if you're already using it for a bunch of other stuff in the same application, that seems like a pretty minor concern. I also don't understand the hate for moc. It's certainly not the most elegant solution, and far from perfect, but it's effective and 99% of the time you can pretty much forget that it's even happening in the background.
slavik81 10y ago
Originally they made their containers because the standard library implementation was broken or incomplete on many platforms they supported. These days that's not such an issue, but avoiding the standard types allows them to make stronger binary compatibility guarantees. I think it's a rather nice supplement to the STL. Their containers are optimized quite differently. For instance, all the Qt containers are copy-on-write. Also, note that QList is not a linked list. QLinkedList is the counterpart to std::list.
jernfrost 10y ago
Actually Qt collections are better designed as they work like regular collections in other languages with e.g. copy on write, making regular copies cheap etc. STL is extremely low level and not as well suited for application programming which you typically do with Qt.
defiancedigital 10y ago
I'm not disturb by moc. Meta object/programmation is a modern approach of OO.

I want to like Qt but I hate that it needs moc. Also I don't like that it doesn't use much of the STL - it forces you to use classes like "QVector" and "QList" instead of std::vector and std::list.

lossolo 10y ago

You can use std as much as you want. Qt doesn't force you to use their containers. Moc is not a problem anymore also, it's more an a myth now than anything else.

jlarocco 10y ago
That may be technically true, but programs using the std containers have to convert at some point if the data has to show up in the GUI. There may be some really clever ways to avoid a bunch of copying and string conversions, but by default there will be a bit of overhead converting back and forth. I'm not sure what you mean by "Moc is not a problem anymore, ...". AFAICT, Moc is still used by Qt and is at least still in their documentation. http://doc.qt.io/qt-5/why-moc.html http://doc.qt.io/qt-5/why-moc.html I'm personally not too bothered by Moc and see it as a trade off of using Qt. I'd prefer a cleaner "pure" C++ solution, but I don't know of any GUI toolkits as nice as Qt without Moc. Qt is still my preferred GUI framework, and I use it from C++, Python, and lately Common Lisp. My biggest complaints are the way it's been increasingly tied to Qt Creator and the focus on Qt Quick and QML.

RotsiserMho 10y ago

I avoided Qt for a long time due to what I'd heard about moc being required. However recent versions support connecting lambdas to slots which is sufficient for my relatively simple application to avoid using moc to set up signals/slots.

symlinkk 10y ago
Do you have a link that shows how to compile a Qt app without moc? I looked specifically for this and could only find this, which is unofficial and contains a bunch of ugly macros: https://woboq.com/blog/verdigris-qt-without-moc.html https://woboq.com/blog/verdigris-qt-without-moc.html
- carewolf 10y ago
  Just don't use slots.
defiancedigital 10y ago
You should consider that c++ lambdas does not offer the same level of connection that signal/slot does (direct,queue,blocking,unique) ...
- RotsiserMho 10y ago
  True, but a lot of that functionality can be gained using boost::signals2 and a simple cross-thread queue. (though some may question the wisdom of trading one dependency for another, I prefer my dependencies decoupled from each other). Still, as I said, lambdas are enough for my simple application.

zanny 10y ago

Theres a neat project in the works: https://github.com/woboq/verdigris https://github.com/woboq/verdigris Unlike Copperspice, the other MOC-less Qt, this one is API compatible with Qt itself, you just include it and drop the MOC and use its functions instead of the original library ones and it can connect to normal Qt data structures. And like others have said, you can use as few or as many Qt data structures as you want. The problem is that if you end up using Qt IO, you end up getting QStrings and QVariants, which you usually want to keep that way and end up using containers that recognize those types. If we had a good C++ var type, and a usable string class, there would be an argument to depreciate whats there, but even Qt cannot do utf-8 right (QString is utf-16).

VeejayRampay 10y ago
For those interested in such things, verdigris comes from the French "vert de gris", which is the colloquial name for copper oxide (translates to green of grey or grey's green).

coldtea 10y ago

>Also I don't like that it doesn't use much of the STL - it forces you to use classes like "QVector" and "QList" Which are quite better designed, more lightweight and better suited to the GUI tasks -- not to mention take less time to compile when used. Of course if you want you can also use STL.

dkersten 10y ago

Serious question because I'm curious: what is the problem with the MOC? Sure, its another build step, but so what? I mean, most large complex software has numerous build steps and MOC is pretty straightforward (and if you use QMake or QtCreator, its pretty much invisible to the programmer). I'm trying to understand why people dislike it so much.

RotsiserMho 10y ago
My problem with it is the fact that it inserts itself in my otherwise standard-conformant C++ code; right in the middle of class declarations. If I decide I want to use another GUI framework I'd have to refactor that code. Most other build steps occur before or after compilation and are far less intrusive. In short, it's too tightly-coupled to application code.
- dkersten 10y ago
  You mean stuff like the "signal" and "slot" declarations in the class definition? Wouldn't these types of classes be tied to the GUI framework anyway due to the inherited classes, implemented virtual functions, widget classes referenced and so forth? In my experience (having used Qt, GTK, FOX, FLTK and wxWidgets over the years), different GUI frameworks are significantly different in their APIs and how they work, to the point where I think changing existing code from any of these to any other is a very difficult job, with or without moc.
- joezydeco 10y ago
  If I decide I want to use another GUI framework I'd have to refactor that code. If you're already developing in Qt, what do you think the probability of that is? Personally MOC is worth the price of admission just to have signals transparently marshaled and queued across threads. It makes life incredibly easy.
Too 10y ago
It pretends to be c++ but it doesn't support all features and it fails silently during compile time when you don't use it in the exact specific way, problems first arrive at runtime. Some examples of seemingly simple things that just dont work without wrestling or not at all: Objects referring to other types of objects, enum class, 'using' aliases, stdint types, namespaces. Signal slot connections are not compile time type safe. The make process is also broken as sometimes it doesn't understand which files should be rebuilt so you have to force it by removing all generated files.

fisherjeff 10y ago

I actually find their container classes to be much more usable than the STL containers. Obviously that locks you in to Qt, but if you're already using it for a bunch of other stuff in the same application, that seems like a pretty minor concern. I also don't understand the hate for moc. It's certainly not the most elegant solution, and far from perfect, but it's effective and 99% of the time you can pretty much forget that it's even happening in the background.

slavik81 10y ago

Originally they made their containers because the standard library implementation was broken or incomplete on many platforms they supported. These days that's not such an issue, but avoiding the standard types allows them to make stronger binary compatibility guarantees. I think it's a rather nice supplement to the STL. Their containers are optimized quite differently. For instance, all the Qt containers are copy-on-write. Also, note that QList is not a linked list. QLinkedList is the counterpart to std::list.

jernfrost 10y ago

Actually Qt collections are better designed as they work like regular collections in other languages with e.g. copy on write, making regular copies cheap etc. STL is extremely low level and not as well suited for application programming which you typically do with Qt.

defiancedigital 10y ago

I'm not disturb by moc. Meta object/programmation is a modern approach of OO.