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