View source for Moc in 202x and beyond

[[Category:QtCS2023]]

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