- https://woboq.com/blog/reflection-in-cpp-and-qt-moc.html 2014, That was based on a previous reflection proposal
- https://github.com/woboq/verdigris : 2016, Replaces the moc by a set of macros.
What my verdigris experience shows is that it is perfectly possible to replace the moc at the cost of slightly uglier macros. And this was using C++14. I haven't look in details at the C++26 reflection, but I'm sure it would make it easier to make these macro more pretty.
Most likely the raise of AOT compiled alternatives, for scenarios where C and C++ were only being used due to being compiled languages, big names in C++ compiler world rather put money on their own alternatives, are the two main reasons of the slow down.
- https://en.cppreference.com/w/cpp/compiler_support.html
- https://en.cppreference.com/w/cpp/compiler_support/17.html
- https://en.cppreference.com/w/cpp/compiler_support/14.html
What alternatives?
Rust claws at market share but has problems with basic stuff like doubly linked lists, WIP gccrs and memory unsafety, Carbon looks like a meme with too few people working on it, Ada has a neglected dialect and a proprietary dialect, Go has garbage collection, Zig has not even reached 1.0, Swift is more of an application language than a systems language, Circle is dead.
What else is there?
Not that C++ doesn't have challenges.
Doubly linked lists aren’t that important today. Rust doesn’t need gccrs to be useful, and it gives much better memory safety than C++ without needing a GC. So I find your criticism of Rust seems a bit weak. Rust is a strong alternative to C++.
I guess Rust is just not a viable or good language if one cannot even implement easily something as basic as a doubly linked list. Doubly linked list is the bare minimum; if that is not easy to implement, more complex data structures will often be even worse.
Rust, contrary to public claims, often does worse on memory safety than C++, which is a sad state of affairs.
I fear my arguments are way stronger than yours, sorry. Please make it easier to implement data structures in Rust.
Nonsense! Where do you get that from?
Aslo, you can make easily make linked list, it's just not a recommended data structure.
On doubly linked lists: Sorry, but to implement a doubly linked list in Rust well, you have to go through trials and tribulations. A whole book was written about an epic of implementing doubly linked lists in Rust: https://rust-unofficial.github.io/too-many-lists/ . And if all that is required for a data structure as simple as a doubly linked list, what will then be required for some of the more complex data structures?
Many people that use C and C++, do it out of habit, any compiled language, even with AOT is capable to deliver for most scenarios in userspace code.
99% of user software written in compiled languages isn't systems programming juggling pointers and type casts.
Even when that is the case, all above languages have FFI features, no need to rewrite the whole thing.
You might have noticed that C and C++ are minority languages in the mobile OS duopoly, for starters, being used only for low level OS services, and game engines.
And, I already mentioned Go, Swift and Ada.
Objective-C is not really on my radar, it's specific to Apple, and it doesn't seem like Apple is betting on it for the future.
D and Nim are languages with low momentum relative to others.
I am not sure the AOT approach will work. Maybe, maybe not. There are direct and indirect obstacles, I believe. D is probably interesting here; as I understand it, it supported both GC and no-GC. But, that meant that a lot of libraries used GC, and thus were not necessarily good options for applications that required no-GC. In some ways, a programming language can also be what people build with it and what its ecosystems are like.
What on earth are you on about? That’s not the case.
Ada 2022 has been released and Ada 202x is getting improvements. Those features are trickling into FSF GNAT (GCC).
Are you talking about the SPARK dialect, where GNATprove is open source?
I find the Ada community difficult to navigate, the existence of multiple dialects does not make it easier. Please do correct me if I am wrong, and I apologize for any mistakes that I might have made.
If it is not the case that the SPARK language or its proprietary compiler is ahead of what is available publicly, why does this page say that pattern matching is in production:
https://github.com/AdaCore/ada-spark-rfcs/blob/master/featur...
While as far as I can tell, it is not part of normal, not-SPARK Ada, and either is not available in open source compilers, or might require enabling an extension?
> Use at your own risks[sic]!
>This is very much an Alpha quality release, at best.
Last update 1 year ago.
Unsafety.
Interesting research, however.
There’s Nim, which is getting a major overhaul for v3 (cf. Nimony).
In general, not for Qt deployment scenarios, also take into consideration the surviving big iron UNIX, mainframes and micros still in business, again the compilers that are yet not clang forks.
The table is a non exaustive overview, however it also paints the picture that for those that care about real portable code, regular visits to the table are required before considering adopting any specific new feature, or the need to enforce style guides like "we use C++20, but feature X, Y, Z are forbidden due to lack of portablity".
I used to use Qt quite extensively years ago, and it seemed that all MOC was really bringing to the table was signal-slot connections which can certainly be done in much nicer ways (e.g. just use std::function to represent signals).
The linked article goes into detail on what are the use cases for MOC and what are the shortcomings of C++26 to completely replace MOC with C++ reflections.
If you read the article, the goal they are aiming for is replacing MOC with C++ reflections without requiring fundamental changes to how Qt works. There are many reputable and very stable signal&slots implementations in C++ that are both type safe and do not require reflection at all. Some of these projects exist for over a decade already, and required only C++14. But Qt's implementations of signals and slots require far more than that to have a drop-in replacement.
I'm no longer familiar with Qt nor C++, but I guess the real blocker here is that the Qt foundation is only looking for ways that are 100% backward-compatible to inccur no change in its commercial userbase? Or am I missing something more subtle?
Non-commercial users also care about backwards compatibility.
Also FWIW Qt does break backwards compatibility in major versions, though the breakage isn't huge. And regardless of commercial or non-commercial, it is in general a good idea to avoid breaking people's working code.
That's perfectly fine. Copperspice didn't aimed to support legacy code, and thus could introduce backwards incompatible changes without looking back.
Dropping support for legacy Qt code also ensured it was automatically irrelevant, which is why most people in a thread over Qt have absolutely no idea what copperspice is, let alone that it existed for over a decade.
I was always uncomfortable with MOC - the rest of Qt was great, so you put up with MOC, but I was always hoping they might have moved away from it as C++ got more powerful.
In general I got into Qt wanting a nice GUI toolkit for C++ on Linux. The cross-platform support was a bonus, but not something that I ever actually used. MOC was already an unwanted step away from pure C++ development, and QML would have been another one. At the same time Qt Quick and QML support seemed to suck all the wind out of further Qt development for desktop use.
Also, most QML components are just C++ objects exposing QML api. And I think there are some compile flags to convert QML to C++ (even some JS code).
Well, evidentially you chose/prefer that stack over Qt Widgets, presumably for some considered reason (unless it was just Nokia pushing that as the future, per their own mobile interests).
There was definitely a change of focus when Nokia bought Trolltech. For me it was a negative one.
Does this motivate me to go back into all my C++/Qt projects and try to un-MOC-ify them? No. But if I started a new project, maybe I'd try to do with without MOC and instead do more in handwritten C++ code.
It also never supported the whole Qt tooling ecosystem.
C++ is such a dinosaur, that even after all these years the reflection that was lacking and was introduced is still unusable.