Moc in 202x and beyond: Difference between revisions
Jump to navigation
Jump to search
(Created page with "Category:QtCS2023 ==Session Summary== ==Session Owners== ==Notes==") |
No edit summary |
||
Line 2: | Line 2: | ||
==Session Summary== | ==Session Summary== | ||
Fabian presented what moc currently does (transform C++ and JSON to C++ and more JSON), and the challenge that, by being a 'glorified preprocessor', it fails to parse more complex / modern C++ code. | |||
==Session Owners== | ==Session Owners== | ||
Fabian Kosmale (maintainer of moc) | |||
==Notes== | ==Notes== | ||
Notestaker: Kai Koehne | |||
MOC input: | |||
* C++ (Qt) | |||
* JSON (for plugins) | |||
MOC output: | |||
* C++ | |||
* JSON (with metadata for QML, Remote Objects (replicants) | |||
Challenge: Parsing C++ | |||
* "glorified preprocessor" | |||
** doesn't know much about newer C++ features | |||
Using clang? | |||
* Full compiler makes it very slow | |||
* Integrating into clang as plugin? | |||
** Solution only for one toolchain | |||
Hope on C++ reflection? | |||
* Recent progress, possible for C++ 26 | |||
** Means it's very far in the future until Qt can rely on it | |||
* Can and should we help shapeing its development? | |||
** MOC use case has been on the radar for the C++ standardization, but more as a 'pipedream' | |||
* Can we still limit reflection on single headers (so not scanning say qobject.h again and again)? | |||
** Yes, this is a use case! We can still for instance hide things in a macro, should be able to work around this. Ville will take care of this. | |||
* Even if we don't have to scan C++ anymore, do we still need moc for JSON input processing? | |||
** C++ committee is working on 'embed' feature to allow binary data... | |||
* What about the JSON output? | |||
** Ville: Unlikely that C++ standard will provide 'code injection' facility | |||
What's the actual problem? That moc is a separate tool, or that it is not supporting modern C++? | |||
* Common challenge: Template C++ classes | |||
** Verdigris has this implemented; only for pure C++ though | |||
** C++ reflection will also only work for concrete classes, not templates | |||
Replacing macros with attributes? | |||
* Requires attribute reflection, which is still in the discussions on the committee |
Latest revision as of 12:59, 30 November 2023
Session Summary
Fabian presented what moc currently does (transform C++ and JSON to C++ and more JSON), and the challenge that, by being a 'glorified preprocessor', it fails to parse more complex / modern C++ code.
Session Owners
Fabian Kosmale (maintainer of moc)
Notes
Notestaker: Kai Koehne
MOC input:
- C++ (Qt)
- JSON (for plugins)
MOC output:
- C++
- JSON (with metadata for QML, Remote Objects (replicants)
Challenge: Parsing C++
- "glorified preprocessor"
- doesn't know much about newer C++ features
Using clang?
- Full compiler makes it very slow
- Integrating into clang as plugin?
- Solution only for one toolchain
Hope on C++ reflection?
- Recent progress, possible for C++ 26
- Means it's very far in the future until Qt can rely on it
- Can and should we help shapeing its development?
- MOC use case has been on the radar for the C++ standardization, but more as a 'pipedream'
- Can we still limit reflection on single headers (so not scanning say qobject.h again and again)?
- Yes, this is a use case! We can still for instance hide things in a macro, should be able to work around this. Ville will take care of this.
- Even if we don't have to scan C++ anymore, do we still need moc for JSON input processing?
- C++ committee is working on 'embed' feature to allow binary data...
- What about the JSON output?
- Ville: Unlikely that C++ standard will provide 'code injection' facility
What's the actual problem? That moc is a separate tool, or that it is not supporting modern C++?
- Common challenge: Template C++ classes
- Verdigris has this implemented; only for pure C++ though
- C++ reflection will also only work for concrete classes, not templates
Replacing macros with attributes?
- Requires attribute reflection, which is still in the discussions on the committee