C++ Reflection and Qt MOC | Hacker News Reader

C++ Reflection and Qt MOC

wiki.qt.io

91 pointscoffeeaddict147 comments

10 years ago, in another life, I was already experimenting with trying to provides feature from moc with reflections and from other macros:

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

Even if C++26 covers all scenarios needed for MOC, it is going to take ages until Qt can rely on it being available across all their customer platforms, unfortunely after a spike in the last decades regarding ISO C++ support, the compilers velocity has slowed down, while proprietary compilers have decided to freeze their support somewhere between C++14 and C++17.

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 are all the use cases for MOC?

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

That is what the linked article is about: what moc provides and what the pure C++ equivalent (if any) could be.

If you use QML it does, like... everything? QML can't interact with native C++ at all, you must use the MOC to generate Q_PROPERTYs, signal/slots, the Q_OBJECT macro itself etc.

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

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

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.

> What else is there?

There’s Nim, which is getting a major overhaul for v3 (cf. Nimony).

Go, Java (GraalVM/OpenJ9), .NET (Native AOT, .NET Native, IL2CPP, Mono AOT), Swift, Objective-C, D, Nim, Ada.

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.

I think it is fine for C and C++ to be relegated for use caches where they make the most sense. I don't see the point of comparing them to niches, markets or cases where for instance garbage collection is fine.

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.

> Rust claws at market share but has problems with basic stuff like doubly linked lists, WIP gccrs and memory unsafety,

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

> Doubly linked lists aren’t that important today.

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.

> Rust, contrary to public claims, often does worse on memory safety than C++, which is a sad state of affairs.

Nonsense! Where do you get that from?

Aslo, you can make easily make linked list, it's just not a recommended data structure.

On memory unsafe Rust: It tends to come crashing down when unsafe is necessary, for both reasoning about unsafe is harder than in C++, and the rules for unsafe in Rust is an active area of research. Do you know all the intricate rules of unsafe (not all which have been defined), can you reliably predict what is safe and what is not without using Miri? Miri that cannot test all? Are you an expert on aliasing and pinning? Can you describe what tree borrows are?

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?

Well said, the point of doubly linked lists is not that it is the be all and end all of all data structures. You can possibly workaround that. The real issue is a real program has much more complex data structures, how can you possibly make it work or refactor easily when a simple thing like DLL's are causing so much grief. So, yeah Rust really is unproductive in a massive way. Just useful in small parts where you might really need memory safety (that too, not sure why you wouldn't chose another language).

as for rust linked list

https://crates.io/crates/ghost-cell

That seems more an argument against Rust than one for, sorry. Library assistance, not part of the standard library, does not seem to be used much, not many examples.

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

>Ada has a neglected dialect and a proprietary dialect

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?

It was indeed the SPARK dialect I am referring to.

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?

My apologies for getting frustrated. I shouldn’t have done that.

This is bit on info-dump. I’m not the best at expressing myself and so some parts may not be clear. Please feel free to ask for clarification or any further questions.

Pattern matching is available as a language extension (currently) exclusive to GNAT GCC. It’s not in the reference manual, which means it’s not part of standardised Ada (yet). It’s intended to be an experiment or prototype for what will eventually become a standardised language feature (the standardised feature may be different, or it could be rejected, as the standardisation committee is composed of multiple compiler vendors).

As is, that pattern matching feature works in both normal Ada and in SPARK mode on GNAT GCC 15.2. The flag to enable it is “-gnatX0”. Please see these: https://godbolt.org/z/d55ddznfn https://gcc.gnu.org/onlinedocs/gnat_rm/Case-pattern-matching... https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gnat_rm/How-to-act... In the Godbolt example, that is in normal Ada.

You are not alone in finding the Ada community difficult to navigate. The “ada-spark-rfcs” repository you linked is a community outreach program of AdaCore to solicit feedback from programmers in venues they’re more likely to use. Those RFCs are then forwarded to the Ada Rapporteurs Group (ARG) who focus on the development of standardised Ada. Their issues, mailing list and meeting minutes can be found at: http://www.ada-auth.org/arg.html

SPARK doesn’t add features to Ada; instead, it’s a subset of features that can be easily proven by SMTs for formal verification. The special things in SPARK (extra attributes and pragmas, which Ada implementations are allowed to define) are only to aid formal verification. When language features are added, they’re added to Ada first and subsequently potentially enabled in SPARK.

I admit that calling it “ada-spark-rfcs” is kinda confusing - it’s just dumping ground for ideas for Ada and SPARK. For example, the multiple ghost levels RFC really only applies to SPARK, as ghost code only exists to improve verifiability. The final modifier RFC is for Ada proper, and it’ll probably apply to SPARK as it allows OOP.

The situation regarding compiler available is confusing and it made me nervous when I was first learning about the language.

GNAT GCC has two versions: FSF and PRO. The FSF (as in the Free Software Foundation) version is the publicly available version that’s in mainline GCC. PRO is for paying customers of AdaCore. From what I can tell, it’s built against an older version of the GCC backend. It tends to get those newest experimental features sooner, but they do trickle into FSF GCC. There have been points in time where I haven’t noticed any difference in feature set between GNAT PRO (according to the release notes) and those in FSF.

SPARK code works with both GNAT FSF and GNAT PRO. The formal verification tool for SPARK, GNATprove, is open source. https://github.com/AdaCore/spark2014

Have a great day. :)

Edit: I’m not affiliated with AdaCore. I’ve never even spoken to one of their employees on the forums. I do use Ada, but only in my “side-business” (not making any money yet lol).

Where are you seeing proprietary compilers freezing support after C++17. C++20 support is almost green across the board (even Cray) and C++23 is getting there. As usual there is a lag, for ex. when nvcc will declare C++23 support and whole swath will turn green. Right now it only supports C++20 (but you can mix in C++23 files and link them together) etc.. I see most C++ projects make C++20 a minimum. (not counting someone who wants to keep running C++98).

Easy, go hunting their manuals for the compilers that aren't yet another clang fork, still a few around between TI, Microchip and co on embedded.

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

But Qt doesn't care for microcontrollers, nor mainframes. The most exotic target they have is QNX, but "Qt needs C++XX" seems to be a pretty good motivator for QNX to update their compilers, which are gcc-based after all.

They care about all of these,

https://doc.qt.io/qt-6/supported-platforms.html

I do see exotic stuff like INTEGRITY as well, still the point stands all those platforms listed on the page have to support C++26 in the Compiler column as the reference compiler.

Meanwhile, copperspice got rid of the MOC more than 10 years ago.

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?

I wasn't aware of Copperspice, but would have been tempted to use it. Qt seemed to have lost it's way when it started with Qt Quick and QML and deemphasized it's roots as a cross-platform library with widget-based UI.

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.

I was always kind of uncomfortable with MOC too, but I couldn't really articulate why. I consider it "wizardry that works but I don't understand" and I never bothered to go in and really understand it. The more I program though, the less I want any kind of "wizardry" in my code, whether or not I understand it.

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.

MOC just seemed to me like an unnecessary hack - an unwanted layer between me and my C++ code that was hard to justify. I suppose it may have served more of a purpose in the early days of Qt (1st release was 1995), but IMO could/should have been phased out when C++11 came along with things like std::function well suited to signals & slots.

What exactly are your qualms with Qt Quick and QML? I find the separation of UI (QML) and logic (C++) pretty amazing. QML is such a nice language and the framework has grown a lot over the years. I developed a block editor (Notion style) in QML and C++, wrote about it in my blog[1].

[1] https://rubymamistvalove.com/block-editor

For my taste there was already enough separation of UI and logic in a widget-based UI with callbacks or signals/slots. I was using Qt for desktop app development, so didn't see any benefit to Qt Quick and QML which seemed more intended for mobile, and a step away from native desktop feel. Qt Designer also helped separate UI from logic, but although it was great I found it didn't quite hit the mark. I would use it for prototyping, but then reimplement for real.

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.

I still don't hear any concrete feedback regarding QML and Qt Quick - the stack is very suited to desktop apps as well. My FOSS app (1,500,000 downloads) has a Kanban UI written in QML[1] and people seems to like it. I do think the choice of Javascript as the scripting language for QML is not ideal to say the least (although there were some improvements to type safety like using `required` in model-view, etc).

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

[1] https://www.notes-foss.com

> I still don't hear any concrete feedback regarding QML and Qt Quick

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.

Not the one you asked, but since I share the exact same feeling, and for what it's worth: I used to reach for Qt when I needed a complex desktop app, the kind of app with a high density of widgets, controls and information, great care for UI but little for aestetic. QML felt to me like it was going in the direction of web development, up to a point where you'd be better off having a separate front-end and back-end, all in the name of more eye candy.

I understand their worries, but it was not my need (and it felt patheticaly hopeless). When I need a web app, I go for a web app

Like most forks, it seldom gets used by the large majority that still cares about Qt.

It also never supported the whole Qt tooling ecosystem.

> Meanwhile, copperspice got rid of the MOC more than 10 years ago.

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.

> looking for ways that are 100% backward-compatible to inccur no change in its commercial userbase?

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.

just curious, why hasn't Qt (the qt project/company) proposed a reflection/meta system into std c++?

Comment in the issue referring to the wiki page: "note: it needs updates for stuff merged in Sofia".

related: https://www.copperspice.com/

Moc is complex. reflection is complex. round one was trying to be as simple as possible while still allowing some real world use and allow room for the future.

Moc?

Meta-Object Compiler, a sort of preprocessor for code that uses Qt: https://doc.qt.io/qt-6/moc.html

"Reflection in C++26 might be insufficient for replacing moc."

C++ is such a dinosaur, that even after all these years the reflection that was lacking and was introduced is still unusable.

A dinosaur without which all the languages that build on top of GCC and LLVM would not exist.

C++ is like Bagger 288! The C stands for Coal.

https://www.youtube.com/watch?v=azEvfD4C6ow

Now that was a thrown back to this kind of tunes! :)

Reply on news.ycombinator.com