Hi Elias,
let's get your second question out of the way: Doesn't Q_PROPERTY(Qstring text
MEMBER m_text) cover that already?
Now, for the actual question, moc supporting modules: That certainly wasn't a
priority before CMake had official
support for modules, but granted, they do now support them, and the three big
compilers have at least some
amount support for them. Still, I haven't seen much (Qt Company) customer
demand there, though
as the ticket shows, there is quite a bit of community interest.
What would be needed to actually get module support into moc?
1. moc's parsing logic needs to learn about the relevant new keywords. moc
needs to know at the very least the
module (partition)'s name.
2. The generator needs to be adjusted to actually create valid code (basically
what's described in the referenced bug).
I expect some challenges there (e.g. what if your custom Q_OBJECT is only
in an internal partition, but not in the
primary module interface, can moc then find all necessary imports?), but I
guess the most trivial cases could
be supported without too much work.
But I suspect your more interested in timelines, not the details of what the
work entails. The ship has already sailed
for Qt 6.7. If we want this feature in Qt 6.8, I see two ways forward:
- Someone contributes patches. As moc's maintainer, I can promise to review
them timely
- There is enough interest (e.g. voiced here on the mailing list here, or by
customers via support) that I can justify
working on that feature myself.
If neither of the two happen, I expect this to slip to 6.9 (but then to be
picked up for 6.9 due to the expected general
push for mandatory C++20 support in Qt)
Lastly, as mentioned on this year's Qt contributor summit, moc's current
architecture as a glorified preprocessor
comes with its own challenges. I totally expect that to bite us when it comes
to more interesting module use cases,
but it's not a blocker for getting support for the "easy" parts in.
Fabian
________________________________________
Von: Development <development-boun...@qt-project.org> im Auftrag von Elias
Steurer via Development <development@qt-project.org>
Gesendet: Freitag, 15. Dezember 2023 14:36
An: development@qt-project.org
Betreff: [Development] Request for early MOC support for C++20 Modules
Hi Devs,
I'd like to ask about a possible roadmap update regarding C++20 modules support
in moc. There was a discussion a while ago about C++20/23 support for Qt
(https://lists.qt-project.org/pipermail/development/2023-May/043823.html), and
I would like to know if there has been any internal update. The corresponding
bug report is https://bugreports.qt.io/browse/QTBUG-86697, but it seems that
even more bump comments will not help. This is about ensuring moc can handle
modules, not about converting Qt itself into a module. Getting moc ready for
C++20 modules is something that could be done now, well in advance of Qt 6.9.
For me, this is the only, and biggest, roadblock to adding modules support in
my apps. Also, we shouldn't forget about tools like the QtRemoteObjects
compiler that translates .rep files into .cpp/.h files (and possibly others?)
that need updating too.
On a related note, when moving a class to modules, it would be handy to have a
way to skip the 'Generate Missing Q_PROPERTY Members' boilerplate code. My
current classes are mostly 50% getter/setter boilerplate, and in my opinion,
this is only manageable because we split our code into header and source files.
This will be gone when using modules. So, I would like to see something like
Q_PROP(QString text), that generates default get/set/notify code, and if
needed, one could still use the old Q_PROPERTY(QString text READ text WRITE
setText NOTIFY textChanged FINAL) if they need to add additional logic into the
get/set functions.
Cheers,
Elias Steurer
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
