Moc in 202x and beyond

From Qt Wiki
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