Qt Contributors Summit 2019 - moc and QMetaObject: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
(Add to category QtCS2019)
 
(12 intermediate revisions by one other user not shown)
Line 1: Line 1:
[[Category:QtCS2019]]
* breaking ABI allows for performance changes and additional features in QMetaObject
* breaking ABI allows for performance changes and additional features in QMetaObject
* what about newer C++ features
* what about newer C++ features
** raw literals are an issue e.g. like in tests
** 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
*** worse, error handling is confusing and makes it hard for users to know what's going on
** can we use libclang instead of workarounds?
** can we use libclang instead of workarounds? see moc-ng
*** libclang can be quite slow, but we already did it for lupdate and qdoc
*** 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?
*** 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
*** 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 C++ anymore
*** 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
*** 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?
** why can't we use something easier than libclang?
*** parsing C++ is actually very hard with some C++ changes recently
*** 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
*** 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
** 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

Latest revision as of 15:24, 22 November 2019

  • 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