Moc in 202x and beyond

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