4 ms·

C++ Reflection and Qt MOC

91 points by coffeeaddict1 1y ago

deleted 1y ago
[deleted]
Kelteseth 1y ago
Related issue https://bugreports.qt.io/browse/QTBUG-140912 https://bugreports.qt.io/browse/QTBUG-140912
- buovjaga 1y ago
  Comment in the issue referring to the wiki page: "note: it needs updates for stuff merged in Sofia".
pjmlp 1y ago
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.html - https://en.cppreference.com/w/cpp/compiler_support/17.html https://en.cppreference.com/w/cpp/compiler_support/17.html - https://en.cppreference.com/w/cpp/compiler_support/14.html https://en.cppreference.com/w/cpp/compiler_support/14.html
- HarHarVeryFunny 1y ago
  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).
  - badsectoracula 1y ago
    That is what the linked article is about: what moc provides and what the pure C++ equivalent (if any) could be.
  - ghosty141 1y ago
    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.
  - motorest 1y ago
    > 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.
- curious9999 1y ago
  > 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.
  - michaelsbradley 1y ago
    > What else is there? There’s Nim, which is getting a major overhaul for v3 (cf. Nimony).
  - pjmlp 1y ago
    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.
    - curious9999_2 1y ago
      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.
- npalli 1y ago
  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).
  - pjmlp 1y ago
    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".
    - detaro 1y ago
      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.
      - pjmlp 1y ago
        They care about all of these, https://doc.qt.io/qt-6/supported-platforms.html 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.
bluGill 1y ago
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.
5- 1y ago
related: https://www.copperspice.com/ https://www.copperspice.com/
rixed 1y ago
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?
- HarHarVeryFunny 1y ago
  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.
  - ryandrake 1y ago
    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.
    - HarHarVeryFunny 1y ago
      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.
  - rubymamis 1y ago
    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 https://rubymamistvalove.com/block-editor
waynecochran 1y ago
Moc?
- tomovo 1y ago
  Meta-Object Compiler, a sort of preprocessor for code that uses Qt: https://doc.qt.io/qt-6/moc.html https://doc.qt.io/qt-6/moc.html
z3ratul163071 1y ago
"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.
- pjmlp 1y ago
  A dinosaur without which all the languages that build on top of GCC and LLVM would not exist.
  - DonHopkins 1y ago
    C++ is like Bagger 288! The C stands for Coal. https://www.youtube.com/watch?v=azEvfD4C6ow https://www.youtube.com/watch?v=azEvfD4C6ow
    - pjmlp 1y ago
      Now that was a thrown back to this kind of tunes! :)
ogoffart 1y ago
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 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 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.
felixfxu 1y ago
just curious, why hasn't Qt (the qt project/company) proposed a reflection/meta system into std c++?

91 points by coffeeaddict1 1y ago

deleted 1y ago

[deleted]

Kelteseth 1y ago

Related issue https://bugreports.qt.io/browse/QTBUG-140912 https://bugreports.qt.io/browse/QTBUG-140912

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

pjmlp 1y ago

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.html - https://en.cppreference.com/w/cpp/compiler_support/17.html https://en.cppreference.com/w/cpp/compiler_support/17.html - https://en.cppreference.com/w/cpp/compiler_support/14.html https://en.cppreference.com/w/cpp/compiler_support/14.html

HarHarVeryFunny 1y ago
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).
- badsectoracula 1y ago
  That is what the linked article is about: what moc provides and what the pure C++ equivalent (if any) could be.
- ghosty141 1y ago
  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.
- motorest 1y ago
  > 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.
curious9999 1y ago
> 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.
- michaelsbradley 1y ago
  > What else is there? There’s Nim, which is getting a major overhaul for v3 (cf. Nimony).
- pjmlp 1y ago
  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.
  - curious9999_2 1y ago
    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.
npalli 1y ago
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).
- pjmlp 1y ago
  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".
  - detaro 1y ago
    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.
    - pjmlp 1y ago
      They care about all of these, https://doc.qt.io/qt-6/supported-platforms.html 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.

bluGill 1y ago

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.

5- 1y ago

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

rixed 1y ago

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?

HarHarVeryFunny 1y ago
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.
- ryandrake 1y ago
  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.
  - HarHarVeryFunny 1y ago
    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.
- rubymamis 1y ago
  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 https://rubymamistvalove.com/block-editor

waynecochran 1y ago

Moc?

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

z3ratul163071 1y ago

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

pjmlp 1y ago
A dinosaur without which all the languages that build on top of GCC and LLVM would not exist.
- DonHopkins 1y ago
  C++ is like Bagger 288! The C stands for Coal. https://www.youtube.com/watch?v=azEvfD4C6ow https://www.youtube.com/watch?v=azEvfD4C6ow
  - pjmlp 1y ago
    Now that was a thrown back to this kind of tunes! :)

ogoffart 1y ago

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

felixfxu 1y ago

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