Qt Contributors Summit 2019 - moc and QMetaObject

From Qt Wiki
Revision as of 15:24, 22 November 2019 by EdwardWelbourne (talk | contribs) (Add to category QtCS2019)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
  • breaking ABI allows for performance changes and additional features in QMetaObject
  • what about newer C++ features
    • raw literals are an issue e.g. like in tests
      • worse, error handling is confusing and makes it hard for users to know what's going on
    • can we use libclang instead of workarounds? see moc-ng
      • libclang can be quite slow, but we already did it for lupdate and qdoc
      • roughly an order of magnitude slower, but we could do better? => this is the biggest issue probably
      • when using build farms, moc is a bottleneck - unless it could be distributed but that doesn't sound feasible
      • bootstrapping is quasi impossible when using libclang, we'd have to port moc to not use Qt anymore
      • size of libclang + dependencies is only an issue for developer machines, roughly ~80mb
      • windows headers should be supported nowadays
      • libclang C api can be used, C++ api isn't stable, not a good idea probably - need to stay compatible with trunk continuously otherwise
    • why can't we use something easier than libclang?
      • parsing C++ is actually very hard with some C++ changes recently
      • we only need to parse a few things correctly, but we have to ignore all of the rest properly, which is tough
    • for qt6 we could remove old system to use moc without passing include paths, i.e. hard error if file is missing
  • one could add a clang plugin in addition if moc is also "partially" a library that could be reused from elsewhere
    • that would allow us to do moc'ing at compile time to remove any overhead
    • we will get that once refactoring support lands in C++ for real
  • when we need to extend moc, do we extend the old one or do we build a new tool based on top of libclang and add the new features there?
    • who does the work?
    • do we need it in Qt 6?
  • reflection / verdigris
    • proper reflection will help to implement something like verdigris
    • what about the JSON output, that cannot be handled by C++ reflection
      • the JSON files are quasi the better solution to the aweful hack that is qmlplugindump
      • necessary for proper tooling support for QML
      • we could potentially put the JSON data into a separate DSO section instead and read it from there
      • verdigris should have the same knowledge to support all of the info necessary for the tooling side
      • C++ community may need similar features anyways for e.g. generating language bindings (that's also not part of the DSO but it would be e.g. a python file)
    • using the new syntax not something for Qt 6.0 but potentially Qt 7 and otherwise keep an eye on reflection study group and make sure we stay compatible with it
    • verdigris syntax is ugly but it gives us templated QObjects so that's a good thing
      • could be merged into Qt upstream for this specific use case
      • compiling code using verdigris is quite slow but better distributable
  • ulf had an idea about using templates as a different mechanism to implement the introspection stuff -> how? needs more details/research
  • plans for the QMetaObject
    • make as much as possible compile-time, esp. QMetaType and use that more
    • remove string lookups and instead use something faster
    • qMetaTypeId will return a pointer instead of an integer to get compiler errors instead of implicit downcasting to int (source incompat!)
    • we need to find new ways to do e.g. type lookups by name
    • there are open questions regarding opaque types and forward declared types (ptrs in signals/slots) -> someone needs to expand on this, the note taker couldn't follow
    • dynamic QMetaObjects will remain