Moc in 202x and beyond
Jump to navigation
Jump to search
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