Hacker News Reader

Comment by symlinkk | Hacker News Reader

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.

View on HN

Theres a neat project in the works:

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).

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).

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.

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 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.

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.

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

Just don't use slots.

You should consider that c++ lambdas does not offer the same level of connection that signal/slot does (direct,queue,blocking,unique) ...

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.

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.

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.

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.

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.

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.

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.

It pretends to be c++ but it doesn't support all features

It IS C++ though. All of the moc keywords are just macros (that the moc happens to interpret otherwise). signal: is just `#define signal public` and so on. You could compile annotated code without moc without issues.

Signal/slot connections are also compile-time type checked if you use the Qt 5 function pointer syntax: https://woboq.com/blog/new-signals-slots-syntax-in-qt5.html

I won't comment on the rest of what you say, as I don't really know enough about it.

>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.

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.

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.

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

Reply on news.ycombinator.com