Re: [Development] QMetaMethod in Qt 6
On Thursday, 28 May 2020 10:19:58 PDT Adam Light wrote: > I'm including generating moc files in "build time". I'm not saying that > compiling the .cpp files will take significantly longer, but if a .cpp file > has a #include "myclass.moc" type statement, that .cpp file has to be > processed by moc You're talking about when myclass.cpp has a Q_OBJECT. That's the only reason when moc needs to parse that .cpp. But you also don't have a choice. You have to #include the .moc output. We're talking about #include "moc_myclass.cpp", which is when "myclass.h" has a Q_OBJECT. You don't have to have that #include. But if you do, then it's one fewer .cpp file that needs to be compiled. It generates better code and enables more warnings. The only drawback is that the compilation needs to wait for moc to finish. If you have a cluster, it means the cluster can't be used until moc has finished, for that file. But that's only for the first file. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QMetaMethod in Qt 6
On 5/28/20 8:21 PM, Matthew Woehlke wrote: if a .cpp file has a #include "myclass.moc" type statement, that .cpp file has to be processed by moc Huh?*Why*? A direct use case of this is to support having Q_OBJECT classes defined in a .cpp file. That requires moc to parse foo.cpp file and produce foo.moc. The question is, does this happen unconditionally when a #include "foo.moc" appears a .cpp, even if that .cpp is not using Q_OBJECT & friends? Why would it be necessary in this case? My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QMetaMethod in Qt 6
On 28/05/2020 13.19, Adam Light wrote: if a .cpp file has a #include "myclass.moc" type statement, that .cpp file has to be processed by moc Huh? *Why*? AFAIK that's just... wrong. MOC needs to process files that do metaobject things (e.g. use Q_OBJECT). Including a .moc in a .cpp does not affect whether that .cpp does metoobject things. Either you already needed to process it, or you don't, and adding a .moc include doesn't change that. (And your *build system* should be, without doing *any* sort of resolution of includes, processing your input files to determine whether or not to even *invoke* MOC at all.) This sounds like a problem with your build setup. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QMetaMethod in Qt 6
On Thu, May 28, 2020 at 9:55 AM Oswald Buddenhagen < oswald.buddenha...@gmx.de> wrote: > On Thu, May 28, 2020 at 08:43:14AM -0700, Adam Light wrote: > >> [include mocs] > >> > >Changing Qt in a way that would require #including the moc output from > >the .cpp file might cause noticeable increase in build times unless moc > >is also changed. > > > care to explain how _exactly_ that would be the case? your report > demonstrates an issue with _generating_ the moc files, not compiling > them. I'm including generating moc files in "build time". I'm not saying that compiling the .cpp files will take significantly longer, but if a .cpp file has a #include "myclass.moc" type statement, that .cpp file has to be processed by moc, which will require moc to satisfy all other #includes in that .cpp file, which could be significantly slower than if moc processed the class declaration in the .h file, since .h files typically forward declare to the extent possible to minimize the number of included files. As I pointed out in the issue, mocing all files in our application takes about 1/3 of the time of the entire build under the *best* circumstances (see first table in the Possible Solutions, bindflt OFF column). Under non-optimal circumstances (which can be tricky to avoid), mocing all files takes roughly 2.5 times the *rest of the build* combined (same table, compare bindflt OFF versus bindflt ON in Default moc row, also demonstrated in the last table in the Additional complication section, which shows Creator build times). Note that when comparing bindflt ON vs. bindflt OFF times in any of those tables, almost 100% of the difference between ON and OFF is spent in moc.exe. As I explained in Note 1 of the bug report, the VS compiler uses different system API calls to satisfy #includes than moc does, so the compiler itself isn't a bottleneck. Adam ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QMetaMethod in Qt 6
On Thu, May 28, 2020 at 08:43:14AM -0700, Adam Light wrote: [include mocs] Changing Qt in a way that would require #including the moc output from the .cpp file might cause noticeable increase in build times unless moc is also changed. care to explain how _exactly_ that would be the case? your report demonstrates an issue with _generating_ the moc files, not compiling them. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QMetaMethod in Qt 6
On Wed, May 27, 2020 at 8:51 AM Thiago Macieira wrote: > On Wednesday, 27 May 2020 03:42:19 PDT Oswald Buddenhagen wrote: > > > this is not something we can subject our users to. > > > > orly? kde had been doing that for quite a while. > > And I fixed QtCore to do the same. > > The only reason not to include the moc output in your .cpp is if you don't > have one (a header-only class whose only non-inline methods are the moc- > generated ones). Otherwise, #include your mocs. > > That said, we shouldn't enforce this. > > On Windows, the way moc satisfies #includes is very slow, particularly when many (32 in my case) moc processes are running concurrently. Since .cpp files tend to result in many more included files, #including a .moc file from a .cpp file as a regular practice could significantly increase build times, and it also prevents an optimization I came up with that mitigates the poor moc performance (see https://bugreports.qt.io/browse/QTBUG-81348 for details). As core count increases, moc's performance might impact more users, though it may not be obvious to many of them. Changing Qt in a way that would require #including the moc output from the .cpp file might cause noticeable increase in build times unless moc is also changed. Adam ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QMetaMethod in Qt 6
On Thursday, 28 May 2020 02:06:01 PDT Shawn Rutledge wrote: > > On 2020 May 27, at 17:50, Thiago Macieira > > wrote:> > > On Wednesday, 27 May 2020 03:42:19 PDT Oswald Buddenhagen wrote: > >>> this is not something we can subject our users to. > >> > >> orly? kde had been doing that for quite a while. > > > > And I fixed QtCore to do the same. > > > > The only reason not to include the moc output in your .cpp is if you don't > > have one (a header-only class whose only non-inline methods are the moc- > > generated ones). Otherwise, #include your mocs. > > The reason is to speed up compilation, right? Is there another reason? Aside from that benefit and the reason for this thread, it enables some warnings in Clang that aren't otherwise. If it can see all members of a class, including non-inline, it can tell if you forgot to use or initialise some of them. Plus the benefit of more inlining, as there's more the compiler can see. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84441
Il 28/05/20 16:18, Matthew Woehlke ha scritto: While that may be true, changing it now is going to break*every* user that uses these methods to generate compound transformations... and it'll be a silent break. I would be*very* surprised if that doesn't generate more bug reports. I 100% agree, no behavioral changes (clarifications in the docs are welcome) can be made at this point. Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] matrix math help needed - https://bugreports.qt.io/browse/QTBUG-84441
On 27/05/2020 11.09, Giuseppe D'Angelo via Development wrote: Sure, augmenting the docs would help. But the whole point of the API is for its usage to be straightforward. If you do QTransform t; t.translate(); t.rotate(); t.scale(); auto result = t.map(foo); the "obvious" meaning should be that foo is getting first translated, then rotated, then scaled; not the other way around. While that may be true, changing it now is going to break *every* user that uses these methods to generate compound transformations... and it'll be a silent break. I would be *very* surprised if that doesn't generate more bug reports. I think the *absolute best* we could do would be to add an optional parameter specifying in what order to apply the change, defaulted to the old value, with a macro to instead default it to the new value. Maybe we can then, eventually, make defaulting to the old behavior deprecated (either opt-in to the new, or explicitly specify), and eventually remove it and make the new behavior default. But we're probably talking 2-3 release cycles. Is it really worth it? -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QMetaMethod in Qt 6
this is not something we can subject our users to. On Wednesday, 27 May 2020 03:42:19 PDT Oswald Buddenhagen wrote: >>> orly? kde had been doing that for quite a while. On 2020 May 27, at 17:50, Thiago Macieira wrote: >> And I fixed QtCore to do the same. >> >> The only reason not to include the moc output in your .cpp is if you >> don't have one (a header-only class whose only non-inline methods are >> the moc- generated ones). Otherwise, #include your mocs. Shawn Rutledge (28 May 2020 11:06) > The reason is to speed up compilation, right? Is there another reason? Yes, see earlier in this thread: if you #include your .moc in your .cpp, your .h can get away with forward-declaring some classes whose headers it doesn't #include; the .moc may need to see the actual definition, rather than a forward declaration, and the .cpp shall do the needed #include, hence make the definition visible, which the .moc then benefits from by being #included in the .cpp. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Ivan Komissarov as approver
Thanks everybody! Ivan. > 28 мая 2020 г., в 10:50, Alex Blasche написал(а): > > Congrats to Ivan. Approver rights have been set. > > -- > Alex > > > From: Development on behalf of Christian > Kandeler > Sent: Thursday, 7 May 2020 10:23 > To: development@qt-project.org > Subject: [Development] Nominating Ivan Komissarov as approver > > Hello, > > I'd like to nominate Ivan Komissarov as an approver. > Ivan has been doing valuable work in the qbs project for a while now, both as > a contributor and a reviewer. > I trust him to use his approver rights responsibly. > > His commits can be found here: > https://codereview.qt-project.org/q/owner:ABBAPOH%2540gmail.com > > > Best regards, > Christian > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QMetaMethod in Qt 6
> On 2020 May 27, at 17:50, Thiago Macieira wrote: > > On Wednesday, 27 May 2020 03:42:19 PDT Oswald Buddenhagen wrote: >>> this is not something we can subject our users to. >> >> orly? kde had been doing that for quite a while. > > And I fixed QtCore to do the same. > > The only reason not to include the moc output in your .cpp is if you don't > have one (a header-only class whose only non-inline methods are the moc- > generated ones). Otherwise, #include your mocs. The reason is to speed up compilation, right? Is there another reason? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Ivan Komissarov as approver
Congrats to Ivan. Approver rights have been set. -- Alex From: Development on behalf of Christian Kandeler Sent: Thursday, 7 May 2020 10:23 To: development@qt-project.org Subject: [Development] Nominating Ivan Komissarov as approver Hello, I'd like to nominate Ivan Komissarov as an approver. Ivan has been doing valuable work in the qbs project for a while now, both as a contributor and a reviewer. I trust him to use his approver rights responsibly. His commits can be found here: https://codereview.qt-project.org/q/owner:ABBAPOH%2540gmail.com Best regards, Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
