From tmpsantos at gmail.com Wed Mar 1 03:00:34 2017 From: tmpsantos at gmail.com (Thiago Marcos P. Santos) Date: Tue, 28 Feb 2017 18:00:34 -0800 Subject: [Development] Qt 5.9 alpha & mapbox-gl-native on windows ? Message-ID: > But what desktop platform (if any) is most stable right now for mapboxgl? We tested it on OSX, Linux (Ubuntu, but CI bot is passing on RHL and Yocto too), iOS and Android. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Wed Mar 1 08:58:29 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 1 Mar 2017 07:58:29 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <5098997.BicRX6s0W7@tjmaciei-mobl1> <5134146.h9xGcFzzKe@tjmaciei-mobl1> Message-ID: Hi, sorry for answering only now to this thread, I was on vacation last week. Let’s conclude this topic now by moving on towards 5.9 as Tuukka proposed. After some thinking I also agree that this is the best course of action from where we are right now. This is certainly not a great solution, ideally we should have the capability of making both 5.9 in time and push out 5.8 and 5.6 patch level releases. This is currently not working and I’ll be following up on this. My goal is to make sure we identify all the issues in our current release infrastructure, fix at least the worst things that make creating patch level releases difficult until 5.9, and have a clear roadmap for the remaining items. I really don’t want this to happen again. The other thing I’ll take from this is to have another look at the interaction between TQtC and the Qt project. I do see a conflict here in how we handle the release planning between the Company and the Project, and we’ll need to find a better (or more clearly defined and agreed) way on how we jointly create the release roadmap. Cheers, Lars > On 20 Feb 2017, at 13:56, Tuukka Turunen wrote: > > > >> On 18/02/2017, 21.40, "Development on behalf of Thiago Macieira" wrote: >> >> On sábado, 18 de fevereiro de 2017 12:11:53 PST Mat Sutcliffe wrote: >>> On 18 February 2017 at 19:13, Thiago Macieira >>> My point was that this decision happened already on 29 November. That was >>> the original planned release date for 5.8.0, and also the day on which the >>> 5.9.0 initial schedule was set. Could it have been predicted at that time >>> what the consequences might be for 5.8.1? >> >> Hindsight is 20/20. Let's not rehash coulda-woulda-shoulda. >> >> The question is only what to do now. > > What I hope we can do is to have everyone helping to get Qt 5.9.0 out as soon as possible and then make also 5.9.1 soon (although I think we do need to make 5.6.3 in between). > > If we can have the extra help proposed by KDAB and others in the community for making Qt 5.8.1 release geared towards making Qt 5.9 we will be able to make it faster and with higher quality than otherwise possible. > > One concrete item is manual testing of our various snapshots. The sooner these are fully tested, the better. We have CI and RTA test automation, but these do not cover every aspect. Manual testing is needed as well. Often it is a case that a bug is found in quite late release steps, but has actually been there for some time already. Another way to help is making good bug reports that are also notified to the release team. The better the description of the issue, the easier it is to fix it. Third item is of course fixing things quickly – by having more people fixing the issues identified we will be able to close them sooner and thus proceed faster. > > For the CI stability most important thing is to reduce the amount of flaky test cases, which cause failures in CI runs. This in turn both adds delay as well as increases the load of the CI. > > Yours, > > Tuukka > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From denis.shienkov at gmail.com Wed Mar 1 11:27:54 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 1 Mar 2017 13:27:54 +0300 Subject: [Development] There is the wrong behavior with QUdpSocket && EAGAIN on *nix? Message-ID: Hi all, I have use Qt 5.8, and I want to send to the UDP socket many datagrams (e.g. 10000 datagrams, each datagram have 1000 bytes size). I use following code: int busyCounter = 0; for(;;) { ... const QNetworkDatagram datagram(data, m_remoteAddress, Protocol::SlavePort); if (m_dataSocket->writeDatagram(datagram) == -2) { QElapsedTimer timer; timer.start(); const bool result = m_dataSocket->waitForBytesWritten(-1); ++busyCounter; qDebug() << "Wait result:" << result << "nsecs:" << timer.nsecsElapsed() << "busy counter:" << busyCounter; } else { busyCounter = 0; break; } } As I understand, when I got the EAGAIN error (when the writeDatagram() method fails with the error code == -2), it means, that the transmit queue is full, and I need wait for something time, e.g. using the select() function: https://linux.die.net/man/2/sendmsg " When the message does not fit into the send buffer of the socket, *send*() normally blocks, unless the socket has been placed in nonblocking I/O mode. In nonblocking mode it would fail with the error *EAGAIN* or *EWOULDBLOCK* in this case. The *select *(2) call may be used to determine when it is possible to send more data. " and then, as I understand, I need try to send same datagram again. Instead of the select() I use the QUdpSocket::waitForBytesWritten() method, which uses the select/pool/epoll internally. But, seems it does not work, as described in the POSIX documentation, I got following debug output: " Wait result: false nsecs: 363 busy counter: 1 ... Wait result: false nsecs: 140 busy counter: 232 ... Wait result: false nsecs: 167 busy counter: 1 ... Wait result: false nsecs: 139 busy counter: 238 ... Wait result: false nsecs: 167 busy counter: 1 .. Wait result: false nsecs: 167 busy counter: 19 ... " and etc. I suspect, that the busyCounter always should be 1, but it does not happens, and the waitForBytesWritten() always fails! What doing wrong? BR, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Wed Mar 1 11:57:22 2017 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Wed, 1 Mar 2017 10:57:22 +0000 Subject: [Development] CI maintenance break next weekend 4 - 5 Mar 2017 Message-ID: Hi We have scheduled a maintenance break for the CI next weekend. This will cause the CI to be totally offline at least during Sat and could extend over Sun as well. We've planned to do extensive wipe or cleanup to local stored distro images. We have accumulated garbage over the years and the only way to find them is to do deep cleanup. We'll achieve this by wiping all provisioned images and re-cloning the important vanilla templates over to safe location. The builds that are triggered right after we come back online will re-create the provisioned images back again. We will also update vSphere while at it. Regards, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Wed Mar 1 13:13:17 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 1 Mar 2017 12:13:17 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <5098997.BicRX6s0W7@tjmaciei-mobl1> <5134146.h9xGcFzzKe@tjmaciei-mobl1> Message-ID: > On 01 Mar 2017, at 08:58, Lars Knoll wrote: > > Hi, > > sorry for answering only now to this thread, I was on vacation last week. > > Let’s conclude this topic now by moving on towards 5.9 as Tuukka proposed. After some thinking I also agree that this is the best course of action from where we are right now. This also implies that bug fixes should now get pushed to the 5.9 branch and we should close the 5.8 branch soon. Cheers, Lars > > This is certainly not a great solution, ideally we should have the capability of making both 5.9 in time and push out 5.8 and 5.6 patch level releases. This is currently not working and I’ll be following up on this. My goal is to make sure we identify all the issues in our current release infrastructure, fix at least the worst things that make creating patch level releases difficult until 5.9, and have a clear roadmap for the remaining items. I really don’t want this to happen again. > > The other thing I’ll take from this is to have another look at the interaction between TQtC and the Qt project. I do see a conflict here in how we handle the release planning between the Company and the Project, and we’ll need to find a better (or more clearly defined and agreed) way on how we jointly create the release roadmap. > > Cheers, > Lars > >> On 20 Feb 2017, at 13:56, Tuukka Turunen wrote: >> >> >> >>> On 18/02/2017, 21.40, "Development on behalf of Thiago Macieira" wrote: >>> >>> On sábado, 18 de fevereiro de 2017 12:11:53 PST Mat Sutcliffe wrote: >>>> On 18 February 2017 at 19:13, Thiago Macieira >>>> My point was that this decision happened already on 29 November. That was >>>> the original planned release date for 5.8.0, and also the day on which the >>>> 5.9.0 initial schedule was set. Could it have been predicted at that time >>>> what the consequences might be for 5.8.1? >>> >>> Hindsight is 20/20. Let's not rehash coulda-woulda-shoulda. >>> >>> The question is only what to do now. >> >> What I hope we can do is to have everyone helping to get Qt 5.9.0 out as soon as possible and then make also 5.9.1 soon (although I think we do need to make 5.6.3 in between). >> >> If we can have the extra help proposed by KDAB and others in the community for making Qt 5.8.1 release geared towards making Qt 5.9 we will be able to make it faster and with higher quality than otherwise possible. >> >> One concrete item is manual testing of our various snapshots. The sooner these are fully tested, the better. We have CI and RTA test automation, but these do not cover every aspect. Manual testing is needed as well. Often it is a case that a bug is found in quite late release steps, but has actually been there for some time already. Another way to help is making good bug reports that are also notified to the release team. The better the description of the issue, the easier it is to fix it. Third item is of course fixing things quickly – by having more people fixing the issues identified we will be able to close them sooner and thus proceed faster. >> >> For the CI stability most important thing is to reduce the amount of flaky test cases, which cause failures in CI runs. This in turn both adds delay as well as increases the load of the CI. >> >> Yours, >> >> Tuukka >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Wed Mar 1 13:38:47 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 1 Mar 2017 13:38:47 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: Message-ID: <201703011338.47378.marc.mutz@kdab.com> On Wednesday 01 March 2017 13:13:17 Lars Knoll wrote: > > Let’s conclude this topic now by moving on towards 5.9 as Tuukka > > proposed. After some thinking I also agree that this is the best course > > of action from where we are right now. > > This also implies that bug fixes should now get pushed to the 5.9 branch > and we should close the 5.8 branch soon. I disagree. Even if you cannot produce releases from 5.8 anymore, that's our stable branch. 5.9 isn't stable, yet. If you release 5.9.0, *then* you can close 5.8. Do you really want stuff from 5.9 cherry-picked to 5.6? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From ekke at ekkes-corner.org Wed Mar 1 13:52:48 2017 From: ekke at ekkes-corner.org (ekke) Date: Wed, 1 Mar 2017 13:52:48 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201703011338.47378.marc.mutz@kdab.com> References: <201703011338.47378.marc.mutz@kdab.com> Message-ID: Am 01.03.17 um 13:38 schrieb Marc Mutz: > On Wednesday 01 March 2017 13:13:17 Lars Knoll wrote: >>> Let’s conclude this topic now by moving on towards 5.9 as Tuukka >>> proposed. After some thinking I also agree that this is the best course >>> of action from where we are right now. >> This also implies that bug fixes should now get pushed to the 5.9 branch >> and we should close the 5.8 branch soon. > I disagree. Even if you cannot produce releases from 5.8 anymore, that's our > stable branch. 5.9 isn't stable, yet. If you release 5.9.0, *then* you can > close 5.8. Do you really want stuff from 5.9 cherry-picked to 5.6? > > Thanks, > Marc > +1 from me just cherry-picked from 5.8 to get a Show-Stopper-Bug fixed https://appbus.wordpress.com/2017/02/28/patch-qt-5-8-0-for-qtbug-59026/ -- ekke (ekkehard gentz) independent software architect international development native mobile business apps BlackBerry 10 | Qt Mobile (Android, iOS) workshops - trainings - bootcamps *Qt Champion BlackBerry Elite Developer BlackBerry Platinum Enterprise Partner* max-josefs-platz 30, D-83022 rosenheim, germany mailto:ekke at ekkes-corner.org blog: http://ekkes-corner.org apps and more: http://appbus.org twitter: @ekkescorner -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathias.hasselmann at kdab.com Wed Mar 1 13:56:40 2017 From: mathias.hasselmann at kdab.com (Mathias Hasselmann) Date: Wed, 1 Mar 2017 13:56:40 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <18144646.GrGa0AsBTG@tjmaciei-mobl1> References: <5098997.BicRX6s0W7@tjmaciei-mobl1> <14519401487447368@web10g.yandex.ru> <18144646.GrGa0AsBTG@tjmaciei-mobl1> Message-ID: <36e680d8-b506-a361-d845-3613b0d902cd@kdab.com> Am 18.02.2017 um 21:40 schrieb Thiago Macieira: > On sábado, 18 de fevereiro de 2017 11:49:28 PST Konstantin Tokarev wrote: >> 18.02.2017, 22:13, "Thiago Macieira" : >>> On sábado, 18 de fevereiro de 2017 06:36:07 PST Mat Sutcliffe wrote: >>>> Keeping 5.9.0 on schedule even while 5.8.0 blows past its planned >>>> release >>>> date would seem to be appropriate when you have the capability to >>>> concurrently maintain two minor (not patchlevel) release branches. >>> >>> That's exactly what Tuukka proposed we do. We keep 5.9.0 on schedule and, >>> because of that, 5.8.1 becomes impossible and unnecessary. >> >> So people who cannot upgrade to 5.8.0 because of bugs would have to wait for >> 5.9.0 and hope that there will be no other regressions. Great. > > Or wait for 5.9.1. > So let me play the devil's advocate: 5.9.1 also will be canceled for similar arbitrary reasons like vacation plans. Guys, by not delivering bugfix releases for arbitrary reasons we are risking to kill Qt's credibility as reliable toolkit. Our users trust in getting bugfix releases. Ciao, Mathias -- Mathias Hasselmann | mathias.hasselmann at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325485 / +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4016 bytes Desc: S/MIME Cryptographic Signature URL: From edward.welbourne at qt.io Wed Mar 1 15:15:15 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 1 Mar 2017 14:15:15 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <36e680d8-b506-a361-d845-3613b0d902cd@kdab.com> References: <5098997.BicRX6s0W7@tjmaciei-mobl1> <14519401487447368@web10g.yandex.ru> <18144646.GrGa0AsBTG@tjmaciei-mobl1>, <36e680d8-b506-a361-d845-3613b0d902cd@kdab.com> Message-ID: > So let me play the devil's advocate: 5.9.1 also will be canceled for > similar arbitrary reasons like vacation plans. or the universe might end for no readily apparent reason. There is no reason to expect either will happen, though. > Guys, by not delivering bugfix releases for arbitrary reasons we are > risking to kill Qt's credibility as reliable toolkit. Our users trust in > getting bugfix releases. I think it's been made abundantly clear that * there are concrete practical non-arbitrary reasons in this case, * we have a clear plan for how to fix the causes, * there is a clear intent to not skip further releases. This is a one-off caused by problems we do anticipate resolving; and skipping 5.8.1 is how we'll buy the time to resolve them, Eddy. From Kai.Koehne at qt.io Wed Mar 1 15:52:41 2017 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 1 Mar 2017 14:52:41 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201703011338.47378.marc.mutz@kdab.com> References: <201703011338.47378.marc.mutz@kdab.com> Message-ID: > -----Original Message----- > [...] > > This also implies that bug fixes should now get pushed to the 5.9 > > branch and we should close the 5.8 branch soon. > > I disagree. Even if you cannot produce releases from 5.8 anymore, that's our > stable branch. 5.9 isn't stable, yet. If you release 5.9.0, *then* you can close > 5.8. Do you really want stuff from 5.9 cherry-picked to 5.6? Why should a patch merged into 5.8 right now be a better candidate to cherry-picking than one merged into 5.9? It runs through the same scrunity (CI). IMO it's actually harmful to keep 5.8 open if we don't intend to make a release based on it. We keep the overhead of maintaining and merging multiple branches without any benefit. My 2 cents, Kai From thiago.macieira at intel.com Wed Mar 1 20:58:58 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 01 Mar 2017 11:58:58 -0800 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201703011338.47378.marc.mutz@kdab.com> References: <201703011338.47378.marc.mutz@kdab.com> Message-ID: <2932214.lyoQh3unpd@tjmaciei-mobl1> Em quarta-feira, 1 de março de 2017, às 04:38:47 PST, Marc Mutz escreveu: > > This also implies that bug fixes should now get pushed to the 5.9 branch > > and we should close the 5.8 branch soon. > > I disagree. Even if you cannot produce releases from 5.8 anymore, that's our > stable branch. 5.9 isn't stable, yet. If you release 5.9.0, *then* you can > close 5.8. Do you really want stuff from 5.9 cherry-picked to 5.6? We usually switch the default branch between the beta and the RC, so the point is moot. 5.9 will be considered stable in a couple of weeks, so 5.8 can be closed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Mar 1 21:17:39 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 01 Mar 2017 12:17:39 -0800 Subject: [Development] There is the wrong behavior with QUdpSocket && EAGAIN on *nix? In-Reply-To: References: Message-ID: <2591020.eJEzt6400g@tjmaciei-mobl1> Em quarta-feira, 1 de março de 2017, às 02:27:54 PST, Denis Shienkov escreveu: > Hi all, > > I have use Qt 5.8, and I want to send to the UDP socket many datagrams > (e.g. 10000 datagrams, each datagram have 1000 bytes size). > > I use following code: > > int busyCounter = 0; > for(;;) { > ... > const QNetworkDatagram datagram(data, m_remoteAddress, > Protocol::SlavePort); > if (m_dataSocket->writeDatagram(datagram) == -2) { > QElapsedTimer timer; > timer.start(); > const bool result = m_dataSocket->waitForBytesWritten(-1); This isn't needed and isn't useful. QAbstractSocket::waitForBytesWritten has this: if (writeBuffer.isEmpty()) return false; Since QUdpSocket is unbuffered, the write buffer is always empty. So waitForBytesWritten will always return false. > As I understand, when I got the EAGAIN error (when the writeDatagram() > method fails > with the error code == -2), it means, that the transmit queue is full, and > I need wait > for something time, e.g. using the select() function: > > https://linux.die.net/man/2/sendmsg Which is QSocketNotifier. QUdpSocket is unbuffered, so the bytesWritten() signal is not useful. We can't add a readyWrite() signal because it would be fired all the time. You'll have to do the QSocketNotifier. ...unless QUdpSocket already creates one on that socket. The event dispatcher does not allow two QSN on the same socket, with the same type. If that happens, let us know. > and then, as I understand, I need try to send same datagram again. > > Instead of the select() I use the QUdpSocket::waitForBytesWritten() method, > which uses the select/pool/epoll internally. You don't get to poll(). See above. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From denis.shienkov at gmail.com Thu Mar 2 07:43:40 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Thu, 2 Mar 2017 09:43:40 +0300 Subject: [Development] There is the wrong behavior with QUdpSocket && EAGAIN on *nix? In-Reply-To: <2591020.eJEzt6400g@tjmaciei-mobl1> References: <2591020.eJEzt6400g@tjmaciei-mobl1> Message-ID: Hi Thiago, > QAbstractSocket::waitForBytesWritten ... This isn't needed and isn't useful. > QUdpSocket is unbuffered, so the bytesWritten() signal is not useful. > You don't get to poll(). See above. Goood news! :) So, should I create an own wrapper (QIODevice) for the UDP socket? Or there is a solution with QUdpSocket? > ...unless QUdpSocket already creates one on that socket. The event dispatcher > does not allow two QSN on the same socket, with the same type. If that > happens, let us know. Ok, I will try to check it. BR, Denis 2017-03-01 23:17 GMT+03:00 Thiago Macieira : > Em quarta-feira, 1 de março de 2017, às 02:27:54 PST, Denis Shienkov > escreveu: > > Hi all, > > > > I have use Qt 5.8, and I want to send to the UDP socket many datagrams > > (e.g. 10000 datagrams, each datagram have 1000 bytes size). > > > > I use following code: > > > > int busyCounter = 0; > > for(;;) { > > ... > > const QNetworkDatagram datagram(data, m_remoteAddress, > > Protocol::SlavePort); > > if (m_dataSocket->writeDatagram(datagram) == -2) { > > QElapsedTimer timer; > > timer.start(); > > const bool result = m_dataSocket-> > waitForBytesWritten(-1); > > This isn't needed and isn't useful. QAbstractSocket::waitForBytesWritten > has > this: > > if (writeBuffer.isEmpty()) > return false; > > Since QUdpSocket is unbuffered, the write buffer is always empty. So > waitForBytesWritten will always return false. > > > As I understand, when I got the EAGAIN error (when the writeDatagram() > > method fails > > with the error code == -2), it means, that the transmit queue is full, > and > > I need wait > > for something time, e.g. using the select() function: > > > > https://linux.die.net/man/2/sendmsg > > Which is QSocketNotifier. > > QUdpSocket is unbuffered, so the bytesWritten() signal is not useful. We > can't > add a readyWrite() signal because it would be fired all the time. You'll > have > to do the QSocketNotifier. > > ...unless QUdpSocket already creates one on that socket. The event > dispatcher > does not allow two QSN on the same socket, with the same type. If that > happens, let us know. > > > and then, as I understand, I need try to send same datagram again. > > > > Instead of the select() I use the QUdpSocket::waitForBytesWritten() > method, > > which uses the select/pool/epoll internally. > > You don't get to poll(). See above. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Thu Mar 2 08:33:34 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 02 Mar 2017 10:33:34 +0300 Subject: [Development] There is the wrong behavior with QUdpSocket && EAGAIN on *nix? In-Reply-To: References: Message-ID: <2823921488440014@web20g.yandex.ru> 01.03.2017, 13:28, "Denis Shienkov" : > Hi all, > > I have use Qt 5.8, and I want to send to the UDP socket many datagrams > (e.g. 10000 datagrams, each datagram have 1000 bytes size). Totally unrelated to your main issue, but make sure you are using connected UDP socket when sending many datagrams to same host, it should improve performance > > I use following code: > >         int busyCounter = 0; >         for(;;) { >             ... >             const QNetworkDatagram datagram(data, m_remoteAddress, Protocol::SlavePort); >             if (m_dataSocket->writeDatagram(datagram) == -2) { >                 QElapsedTimer timer; >                 timer.start(); >                 const bool result = m_dataSocket->waitForBytesWritten(-1); >                 ++busyCounter; >                 qDebug() << "Wait result:" << result << "nsecs:" << timer.nsecsElapsed() << "busy counter:" << busyCounter; >             } else { >                 busyCounter = 0; >                 break; >             } >         } > > As I understand, when I got the EAGAIN error (when the writeDatagram() method fails > with the error code == -2), it means, that the transmit queue is full, and I need wait > for something time, e.g. using the select() function: > > https://linux.die.net/man/2/sendmsg > > " > When the message does not fit into the send buffer of the socket, send() normally blocks, unless the socket has been placed in nonblocking I/O mode. In nonblocking mode it would fail with the error EAGAIN or EWOULDBLOCK in this case. The select(2) call may be used to determine when it is possible to send more data. > " > > and then, as I understand, I need try to send same datagram again. > > Instead of the select() I use the QUdpSocket::waitForBytesWritten() method, > which uses the select/pool/epoll internally. > > But, seems it does not work, as described in the POSIX documentation, > I got following debug output: > > " > Wait result: false nsecs: 363 busy counter: 1 > ... > Wait result: false nsecs: 140 busy counter: 232 > ... > Wait result: false nsecs: 167 busy counter: 1 > ... > Wait result: false nsecs: 139 busy counter: 238 > ... > Wait result: false nsecs: 167 busy counter: 1 > .. > Wait result: false nsecs: 167 busy counter: 19 > ... > " > > and etc. > > I suspect, that the busyCounter always should be 1, but it does > not happens, and the waitForBytesWritten() always fails! > > What doing wrong? > > BR, > Denis > > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From thiago.macieira at intel.com Thu Mar 2 17:27:24 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 02 Mar 2017 08:27:24 -0800 Subject: [Development] There is the wrong behavior with QUdpSocket && EAGAIN on *nix? In-Reply-To: References: <2591020.eJEzt6400g@tjmaciei-mobl1> Message-ID: <248081041.qnI8kBXS89@tjmaciei-mobl1> Em quarta-feira, 1 de março de 2017, às 22:43:40 PST, Denis Shienkov escreveu: > is a solution with QUdpSocket? > > > ...unless QUdpSocket already creates one on that socket. The event > > dispatcher > > does not allow two QSN on the same socket, with the same type. If that > > happens, let us know. I think we need a togglable readyWrite() signal implementing exactly the solution above. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Thu Mar 2 18:17:57 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 02 Mar 2017 18:17:57 +0100 Subject: [Development] return value of QCoreApplication::testAttribute(Qt::AA_MacDontSwapCtrlAndMeta) Message-ID: <1906598.yi531XS1E6@portia.local> Hello, Should QCoreApplication::testAttribute(Qt::AA_MacDontSwapCtrlAndMeta) return the actual value of the attribute even if it hasn't been set by the user? For me it always returns false when I just want to know whether of not swapping is active, e.g. in the little demonstrator at github:RJVB/menus-qt5.git . R. From giuseppe.dangelo at kdab.com Thu Mar 2 23:36:55 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 2 Mar 2017 23:36:55 +0100 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <1907340.NmBgD95Sl0@tjmaciei-mobl1> References: <201701302003.25214.marc.mutz@kdab.com> <201702202148.50790.marc.mutz@kdab.com> <1907340.NmBgD95Sl0@tjmaciei-mobl1> Message-ID: <8539484e-e27b-618d-aca7-ba2faa3e7ea8@kdab.com> Il 20/02/2017 22:02, Thiago Macieira ha scritto: > I really want QStringView and I'd like to talk to you how Qt6 QString, > QStringView and a non-sharing QString class should cooperate to reduce code > size in QtCore. Something like QString deriving from QStringView. Can we start these discussions, like, now? Could you please share your QString/QVector branch and describe what you did in there and what you think QString should look like in Qt 6? (Similarly, we should start the discussions on containers). I'd like to get to Qt 6 with a very clear plan in mind, having already done all the necessary research, and not starting experimenting with ideas when it's too late -- or even worse having to rush things out and then be stuck another 10 years with suboptimal designs. My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Fri Mar 3 05:48:20 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 02 Mar 2017 20:48:20 -0800 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <8539484e-e27b-618d-aca7-ba2faa3e7ea8@kdab.com> References: <201701302003.25214.marc.mutz@kdab.com> <1907340.NmBgD95Sl0@tjmaciei-mobl1> <8539484e-e27b-618d-aca7-ba2faa3e7ea8@kdab.com> Message-ID: <2070430.AplIAVfVPZ@tjmaciei-mobl1> Em quinta-feira, 2 de março de 2017, às 14:36:55 PST, Giuseppe D'Angelo escreveu: > Can we start these discussions, like, now? Could you please share your > QString/QVector branch and describe what you did in there and what you > think QString should look like in Qt 6? (Similarly, we should start the > discussions on containers). Not sure that discussion is productive now. We're not doing Qt 6 soon, so we can take our time. Maybe at the Contributor Summit. Anyway: https://gitlab.com/thiagomacieira/qtbase This branch rebases often, don't fetch it. It contains everything and the kitchen sink that I've been working on. Some of that I've pushed for review (like part of the QtDBus patches), some of it is unfinished work (like file descriptor passing in QNativeSocketEngine). There are 156 commits as of today. The first 40 commits are related to the QString/QVector/QByteArray work (of which, the first 2 are in 5.9). The work ends in "Handle insert/prepend/append of items in the current vector" -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Mar 3 08:30:09 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 3 Mar 2017 08:30:09 +0100 Subject: [Development] Don't use Private *d when your class is immutable Message-ID: <201703030830.09388.marc.mutz@kdab.com> Hi, If you have a class that just represents a concrete immutable entity, like some system resource's ID, or an SSL elliptic curve algorithm, you can use an enum. Or you can use a class, if you want some richer API than can be had with an enum. In that case, however, *don't* use a Private pointer. The class is immutable, there's no setters, so why should the private parts be implicitly shared? They are naturally globally shared, so just use an int as a member and let the compiler deal with the implementaton of the copy and move special member functions. The property getters just use the int as an index into a global data structure to retrieve the property values. Good example: QSslEllipticCurve. The int is an index into OpenSSL's internal list of elliptic curves, and an int is by what OpenSSL refers to an elliptic curve. Any other backend will either have a library that does the same or needs to provide some central array/vector with the data. Don't be lazy here. The internals are more complicated, but the type is just an int to the compiler. The API is more important than the implementation. Bad example: QSslCipher. Look at all the messy API that just deals with the fact it's pimpled. That class is particularly hideous because it allocates memory on every copy! For fun, I de-pimpled a private class. It saved 2+KiB in text size: https://codereview.qt-project.org/149499 So to the best of our knowledge, a pimpl costs O(KiB) of executable size. Pimpl is not a virtue, it's a burden. Don't use it unless you must. A necessary condition is when there are more than a small, fixed number of states in your class. This condition is not sufficient, however, as witnessed by QString. So, please, when reviewing API (now in the final reviews for 5.9 as well as when adding new API), don't accept classes that end in Info or Id and contain a d-pointer. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From rich at kde.org Fri Mar 3 10:43:56 2017 From: rich at kde.org (Richard Moore) Date: Fri, 3 Mar 2017 09:43:56 +0000 Subject: [Development] Don't use Private *d when your class is immutable In-Reply-To: <201703030830.09388.marc.mutz@kdab.com> References: <201703030830.09388.marc.mutz@kdab.com> Message-ID: On 3 March 2017 at 07:30, Marc Mutz wrote: > Bad example: QSslCipher. Look at all the messy API that just deals with the > fact it's pimpled. That class is particularly hideous because it allocates > memory on every copy! > > ​Please avoid using the SSL code as the example since you don't really understand it. QSslCipher /should/ be an integer index into a table. The fact that it isn't is a poor workaround for weak API from​ openssl and poor design choices when SSL supported was added to Qt. ​Cheers Rich.​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Fri Mar 3 10:59:21 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 3 Mar 2017 09:59:21 +0000 Subject: [Development] Don't use Private *d when your class is immutable In-Reply-To: <201703030830.09388.marc.mutz@kdab.com> References: <201703030830.09388.marc.mutz@kdab.com> Message-ID: <6743E2CB-5FAA-48E5-8C13-14EF03316E99@qt.io> I agree, that we should not use any implicit sharing in those cases. But in many cases, I don’t see a problem using a pointer to the data. Of course if shouldn’t detach. Instead, it should be explicitly shared (with or without refcounting depending on whether the data is generated at compile or runtime). Using an integer and a global lookup table would lead to more complex code in that case. Cheers, Lars > On 03 Mar 2017, at 08:30, Marc Mutz wrote: > > Hi, > > If you have a class that just represents a concrete immutable entity, like > some system resource's ID, or an SSL elliptic curve algorithm, you can use an > enum. > > Or you can use a class, if you want some richer API than can be had with an > enum. > > In that case, however, *don't* use a Private pointer. > > The class is immutable, there's no setters, so why should the private parts be > implicitly shared? They are naturally globally shared, so just use an int as a > member and let the compiler deal with the implementaton of the copy and move > special member functions. The property getters just use the int as an index > into a global data structure to retrieve the property values. > > Good example: QSslEllipticCurve. The int is an index into OpenSSL's internal > list of elliptic curves, and an int is by what OpenSSL refers to an elliptic > curve. Any other backend will either have a library that does the same or > needs to provide some central array/vector with the data. Don't be lazy here. > The internals are more complicated, but the type is just an int to the > compiler. The API is more important than the implementation. > > Bad example: QSslCipher. Look at all the messy API that just deals with the > fact it's pimpled. That class is particularly hideous because it allocates > memory on every copy! > > For fun, I de-pimpled a private class. It saved 2+KiB in text size: > https://codereview.qt-project.org/149499 So to the best of our knowledge, a > pimpl costs O(KiB) of executable size. > > Pimpl is not a virtue, it's a burden. Don't use it unless you must. A > necessary condition is when there are more than a small, fixed number of > states in your class. This condition is not sufficient, however, as witnessed > by QString. > > So, please, when reviewing API (now in the final reviews for 5.9 as well as > when adding new API), don't accept classes that end in Info or Id and contain > a d-pointer. > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tor.arne.vestbo at qt.io Fri Mar 3 12:10:11 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Fri, 3 Mar 2017 12:10:11 +0100 Subject: [Development] Don't use Private *d when your class is immutable In-Reply-To: <6743E2CB-5FAA-48E5-8C13-14EF03316E99@qt.io> References: <201703030830.09388.marc.mutz@kdab.com> <6743E2CB-5FAA-48E5-8C13-14EF03316E99@qt.io> Message-ID: On 03/03/2017 10:59, Lars Knoll wrote: > I agree, that we should not use any implicit sharing in those cases. > But in many cases, I don’t see a problem using a pointer to the data. > Of course if shouldn’t detach. Instead, it should be explicitly > shared (with or without refcounting depending on whether the data is > generated at compile or runtime). Using an integer and a global > lookup table would lead to more complex code in that case. Thank you Lars. +1 tor arne From tor.arne.vestbo at qt.io Fri Mar 3 12:10:11 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Fri, 3 Mar 2017 12:10:11 +0100 Subject: [Development] Don't use Private *d when your class is immutable In-Reply-To: <6743E2CB-5FAA-48E5-8C13-14EF03316E99@qt.io> References: <201703030830.09388.marc.mutz@kdab.com> <6743E2CB-5FAA-48E5-8C13-14EF03316E99@qt.io> Message-ID: On 03/03/2017 10:59, Lars Knoll wrote: > I agree, that we should not use any implicit sharing in those cases. > But in many cases, I don’t see a problem using a pointer to the data. > Of course if shouldn’t detach. Instead, it should be explicitly > shared (with or without refcounting depending on whether the data is > generated at compile or runtime). Using an integer and a global > lookup table would lead to more complex code in that case. Thank you Lars. +1 tor arne From marc.mutz at kdab.com Fri Mar 3 12:19:42 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 3 Mar 2017 12:19:42 +0100 Subject: [Development] Don't use Private *d when your class is immutable In-Reply-To: <6743E2CB-5FAA-48E5-8C13-14EF03316E99@qt.io> References: <201703030830.09388.marc.mutz@kdab.com> <6743E2CB-5FAA-48E5-8C13-14EF03316E99@qt.io> Message-ID: <201703031219.42978.marc.mutz@kdab.com> On Friday 03 March 2017 10:59:21 Lars Knoll wrote: > I agree, that we should not use any implicit sharing in those cases. But in > many cases, I don’t see a problem using a pointer to the data. Of course > if shouldn’t detach. Instead, it should be explicitly shared (with or > without refcounting depending on whether the data is generated at compile > or runtime). Using an integer and a global lookup table would lead to more > complex code in that case. If you have a pointer to static-storage duration data, by all means use that instead of an int, sure. But you're locking yourself into a particular implementation that way, incl. not being able to use a dynamic array because addresses would change on reallocation. Int indexes are stable. But don't - ever- use ref-counting on immutable classes. It's not easier (you need to implement all the special member functions, which peoole, me included[1][2], get wrong more often than we dare to admit). People just *think* ref-counting is easier, because they're used to it and you can just take a similar Qt class, and copy the implementation and it's just harder to copy one with an int index, for lack of widespread use. That doesn't make it good. QFileSelector being a QObject is similar: People are used to inherit from QObject for signals and properties, so they do it every time. That's ok. Unless review doesn't catch it and it gets merged. The simplest implementation of an immutable class that cannot or should not contain all state inline (like QRect) is an int + Q_GLOBAL_STATIC(Container). If you put all init code into the ctor of the Container class, then you get thread-saftey for free, too. Only if you want to add entries dynamically you need to think about threading. And all the special member functions come for free, too, fully optimal (nothrow, inline). People have no problem implementing the business logic (property getters and setters). There're tests for that. They have problems with the boilerplate code, like remembering to add the move assignment operator, making it nothrow (who cares? we compile without exceptions!), the move ctor cannot be inline, they bikeshed over formatting and whether move-assignment uses just swap or move-and-swap... endless potential for problems. Only by ignoring these problems can one think about ref-counting as being easier. It's not. Thanks, Marc [1] https://codereview.qt-project.org/148558 [2] https://codereview.qt- project.org/#/c/167229/3/src/network/ssl/qssldiffiehellmanparameters.cpp,unified -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Fri Mar 3 12:33:06 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 3 Mar 2017 12:33:06 +0100 Subject: [Development] Don't use Private *d when your class is immutable In-Reply-To: References: <201703030830.09388.marc.mutz@kdab.com> Message-ID: <201703031233.06731.marc.mutz@kdab.com> On Friday 03 March 2017 10:43:56 Richard Moore wrote: [...] > QSslCipher should be an integer index into a table. The > fact that it isn't is a poor workaround for weak API from​ openssl Would you mind to expand on that? I don't see any a-priori reason why QSslCipher can't be fixed to contain an index (qintptr), from a BC pov. What in OpenSSL prevents this? > and poor > design choices when SSL supported was added to Qt. Since it was intended as an example for poor design choices, I feel I picked the correct example :) Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From olivier at woboq.com Fri Mar 3 13:37:36 2017 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 03 Mar 2017 13:37:36 +0100 Subject: [Development] Don't use Private *d when your class is immutable In-Reply-To: <201703031219.42978.marc.mutz@kdab.com> References: <201703030830.09388.marc.mutz@kdab.com> <6743E2CB-5FAA-48E5-8C13-14EF03316E99@qt.io> <201703031219.42978.marc.mutz@kdab.com> Message-ID: <4372001.Mt9x3KBcPL@maurice> On Freitag, 3. März 2017 12:19:42 CET Marc Mutz wrote: > But don't - ever- use ref-counting on immutable classes. It's not easier > (you need to implement all the special member functions, which peoole, me > included[1][2], get wrong more often than we dare to admit). refcounting is easy: class FooBarPrivate; class FooBar { public: QString someGetter(); QString someOtherGetter(); FooBar(QString something, QString somethingElse); private: const QSharedPointer d; }; And in the .cpp: class FooBarPrivate { /*...*/ }; FooBar::FooBar(QString a, QString b) : d(QSharedPointer::create(std::move(a), std::move(b))); {} What did i do wrong? With QSharedPointer you can't go wrong, and you don't need to implement any special functions. And because the QSharedPointer keeps the deleter, you don't need the definition of FooBarPrivate to copy/move/destroy the class. The overhead is 16 bytes (refcounts and deleter pointer). Yet, I don't know so many classes that uses QSharedPointer internally. Although it's good practice to still implement the special function out of line in the event in which we cant to add code in them in a future release. But that's actually quite unlikely. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From marc.mutz at kdab.com Fri Mar 3 13:57:56 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 3 Mar 2017 13:57:56 +0100 Subject: [Development] Don't use Private *d when your class is immutable In-Reply-To: <4372001.Mt9x3KBcPL@maurice> References: <201703030830.09388.marc.mutz@kdab.com> <201703031219.42978.marc.mutz@kdab.com> <4372001.Mt9x3KBcPL@maurice> Message-ID: <201703031357.56344.marc.mutz@kdab.com> On Friday 03 March 2017 13:37:36 Olivier Goffart wrote: > On Freitag, 3. März 2017 12:19:42 CET Marc Mutz wrote: > > But don't - ever- use ref-counting on immutable classes. It's not easier > > (you need to implement all the special member functions, which peoole, me > > included[1][2], get wrong more often than we dare to admit). > > refcounting is easy: > > > class FooBarPrivate; > class FooBar { > public: > QString someGetter(); > QString someOtherGetter(); > FooBar(QString something, QString somethingElse); > > private: > const QSharedPointer d; > }; > > And in the .cpp: > class FooBarPrivate { /*...*/ }; > > FooBar::FooBar(QString a, QString b) : > d(QSharedPointer::create(std::move(a), std::move(b))); > {} > > > What did i do wrong? 1. The class is the size of two void*s, which doubles the space requirements over what everyone assumes the size of a pimpled, non-polymorphic class to be (and makes the type unsuitable for QList). 2. The class is not assignable. 3. The class is not default-constructible (don't tell me it's by design; QVector cannot handle such types). 4. You forgot Q_DECLARE_SHARED (which requires member-swap()) And while *you* got it right, for most people we'd need to add: 5. You didn't use QSP::create() Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From rich at kde.org Fri Mar 3 14:38:11 2017 From: rich at kde.org (Richard Moore) Date: Fri, 3 Mar 2017 13:38:11 +0000 Subject: [Development] Don't use Private *d when your class is immutable In-Reply-To: <201703031233.06731.marc.mutz@kdab.com> References: <201703030830.09388.marc.mutz@kdab.com> <201703031233.06731.marc.mutz@kdab.com> Message-ID: On 3 March 2017 at 11:33, Marc Mutz wrote: > On Friday 03 March 2017 10:43:56 Richard Moore wrote: > [...] > > QSslCipher should be an integer index into a table. The > > fact that it isn't is a poor workaround for weak API from​ openssl > > Would you mind to expand on that? I don't see any a-priori reason why > QSslCipher can't be fixed to contain an index (qintptr), from a BC pov. > What > in OpenSSL prevents this? > > In order to present info to the user, QSslCipher lets you see things like the cipher, key length, key exchange method etc. etc. however in SSL these are all bundled together as a cipher suite - this is just a 16 bit number (24 bits in SSLv2). What we'd ideally do is just store the number and then look up the other info as needed. Ideally we'd just query the openssl in use for the list of available ciphers which we could store as a list/vector globally. Unfortunately openssl doesn't provide any API for looking up the info given the id (though i've at least partially got this addressed in openssl 1.1). At the moment the code has to do some horrendous parsing of a text representation. ​ Cheers Rich.​ > > and poor > > design choices when SSL supported was added to Qt. > > Since it was intended as an example for poor design choices, I feel I > picked > the correct example :) > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Mar 3 16:11:54 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 03 Mar 2017 07:11:54 -0800 Subject: [Development] Don't use Private *d when your class is immutable In-Reply-To: <201703031219.42978.marc.mutz@kdab.com> References: <201703030830.09388.marc.mutz@kdab.com> <6743E2CB-5FAA-48E5-8C13-14EF03316E99@qt.io> <201703031219.42978.marc.mutz@kdab.com> Message-ID: <7159555.q5fKD7D9Um@tjmaciei-mobl1> Em sexta-feira, 3 de março de 2017, às 03:19:42 PST, Marc Mutz escreveu: > The simplest implementation of an immutable class that cannot or should not > contain all state inline (like QRect) is an int + > Q_GLOBAL_STATIC(Container). If you put all init code into the ctor of the > Container class, then you get thread-saftey for free, too. Only if you want > to add entries dynamically you need to think about threading. And all the > special member functions come for free, too, fully optimal (nothrow, > inline). Sorry, no. If you need to have a global static to store information, then it sounds wrong. I agree we should use ints, enums and opaque pointers when wrapping a third-party API that is like that. If they have a global table, that's their business. But we should not add more global tables. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Mar 3 16:54:58 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 3 Mar 2017 16:54:58 +0100 Subject: [Development] Don't use Private *d when your class is immutable In-Reply-To: <7159555.q5fKD7D9Um@tjmaciei-mobl1> References: <201703030830.09388.marc.mutz@kdab.com> <201703031219.42978.marc.mutz@kdab.com> <7159555.q5fKD7D9Um@tjmaciei-mobl1> Message-ID: <201703031654.58961.marc.mutz@kdab.com> On Friday 03 March 2017 16:11:54 Thiago Macieira wrote: > But we should not add more global tables. Apart from "Thiago says so", are there any reasons for this? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From lars.knoll at qt.io Fri Mar 3 20:02:18 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 3 Mar 2017 19:02:18 +0000 Subject: [Development] Don't use Private *d when your class is immutable In-Reply-To: <201703031654.58961.marc.mutz@kdab.com> References: <201703030830.09388.marc.mutz@kdab.com> <201703031219.42978.marc.mutz@kdab.com> <7159555.q5fKD7D9Um@tjmaciei-mobl1> <201703031654.58961.marc.mutz@kdab.com> Message-ID: <015B19D8-E7C6-417B-A4B7-78E18B54A193@qt.io> > On 3 Mar 2017, at 16:54, Marc Mutz wrote: > > On Friday 03 March 2017 16:11:54 Thiago Macieira wrote: >> But we should not add more global tables. > > Apart from "Thiago says so", are there any reasons for this? How about: "Lars agrees with Thiago"? ;-) More seriously: constant global tables are perfectly fine. But I fully agree with Thiago that I want to avoid adding more global static data (using Q_GLOBAL_STATIC). Reasons are that those are initialised at startup with an undefined initialisation order (and usually worse: destruction on application shutdown). They thus add overhead for each application (in terms of memory usage and startup time), and can cause headaches on shutdown if there are cross dependencies between global statics (we've had those in the past). Cheers, Lars From kevin.kofler at chello.at Fri Mar 3 23:56:20 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 03 Mar 2017 23:56:20 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 References: <5098997.BicRX6s0W7@tjmaciei-mobl1> <14519401487447368@web10g.yandex.ru> <18144646.GrGa0AsBTG@tjmaciei-mobl1> <36e680d8-b506-a361-d845-3613b0d902cd@kdab.com> Message-ID: Mathias Hasselmann wrote: > Guys, by not delivering bugfix releases for arbitrary reasons we are > risking to kill Qt's credibility as reliable toolkit. Our users trust in > getting bugfix releases. I agree with this. I really don't see why you don't postpone 5.9 instead. Qt used to release on a 9 to 12 month basis, now it is down to 6 months. And for 5.9, not even that, because somehow there is an unrealistic expectation that 5.9 magically makes up for the delays in releasing 5.8. The release schedule for 5.9 should be based on the actual 5.8 release date, not the planned 5.8 release date. The amount of churn is such that some distros are still working on packaging 5.8 while you are already about to branch 5.9. I also agree with Marc Mutz (and no, you have not misread ;-) ) that the way the decision is being dictated onto the community runs counter to the "Open Governance" promises. Kevin Kofler From thiago.macieira at intel.com Sat Mar 4 01:23:09 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 03 Mar 2017 16:23:09 -0800 Subject: [Development] Don't use Private *d when your class is immutable In-Reply-To: <015B19D8-E7C6-417B-A4B7-78E18B54A193@qt.io> References: <201703030830.09388.marc.mutz@kdab.com> <201703031654.58961.marc.mutz@kdab.com> <015B19D8-E7C6-417B-A4B7-78E18B54A193@qt.io> Message-ID: <26117831.vYzcMuIdJt@tjmaciei-mobl1> Em sexta-feira, 3 de março de 2017, às 11:02:18 PST, Lars Knoll escreveu: > > On 3 Mar 2017, at 16:54, Marc Mutz wrote: > > > > On Friday 03 March 2017 16:11:54 Thiago Macieira wrote: > >> But we should not add more global tables. > > > > Apart from "Thiago says so", are there any reasons for this? > > How about: "Lars agrees with Thiago"? ;-) > > More seriously: constant global tables are perfectly fine. Right, so let me clarify: if your table is *constant*, then it's fine. Preferably if your table can be made static read-only, compile-time constructed, like the one I've done for the metatypes in I4139d5f93dcb4b429ae9fffd14a33982891e2ac1. Meta type IDs are, after all, simple integers. (though for Qt 6 we should consider making them opaque pointers) > But I fully agree with Thiago that I want to avoid adding more global static > data (using Q_GLOBAL_STATIC). Reasons are that those are initialised at > startup with an undefined initialisation order (and usually worse: > destruction on application shutdown). They thus add overhead for each > application (in terms of memory usage and startup time), and can cause > headaches on shutdown if there are cross dependencies between global > statics (we've had those in the past). If you have some data that cannot be constructed at compile time, but happens only once, maybe Q_GLOBAL_STATIC may make sense. The arguments that Lars gave above need to be taken into account, so we can't make a blanket statement like you asked to create a global tables. We should make an extra effort to make read-only memory-sharable tables, even if it means creating code generators to do the job. (The Qt Project should be the last project to object code generators *cough* moc *cough* uic *cough* rcc) But I am particularly concerned if the global table can be changed at runtime. Then we need to introduce mutexes and read-write locks in order to achieve the solution. It's trading off one problem (implicit sharing) for another. The example of a bad design here is QSqlDatabase: there's a global table of databases. QDBusConnection (because it was designed on QSqlDatabase) suffers from a similar problem. Worse: QDBusConnection also does ref-counting. Please don't create more of those. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tony.sarajarvi at qt.io Sun Mar 5 14:26:00 2017 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Sun, 5 Mar 2017 13:26:00 +0000 Subject: [Development] CI maintenance break next weekend 4 - 5 Mar 2017 In-Reply-To: References: Message-ID: Hi all! The maintenance break is over. Qt 5.8, 5.9 and dev are building already. For 5.6 we might have a small problem with provisioning openSUSE 13.1. Coin didn't connect to the agent on my previous test yesterday. I'll try to sort this one out ASAP. Also Windows 8 builds might suffer from provisioning passing even though there are provisioning errors in the log. Something we have to have a look at. https://bugreports.qt.io/browse/QTQAINFRA-1178 All in all, I'm quite certain the CI will be more stable from now on. We removed a lot of complexity in the OS images we use and recovered over 15 TB of wasted space on our Compellent. Have fun! -Tony From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Tony Sarajärvi Sent: keskiviikkona 1. maaliskuuta 2017 12.57 To: development at qt-project.org Subject: [Development] CI maintenance break next weekend 4 - 5 Mar 2017 Hi We have scheduled a maintenance break for the CI next weekend. This will cause the CI to be totally offline at least during Sat and could extend over Sun as well. We've planned to do extensive wipe or cleanup to local stored distro images. We have accumulated garbage over the years and the only way to find them is to do deep cleanup. We'll achieve this by wiping all provisioned images and re-cloning the important vanilla templates over to safe location. The builds that are triggered right after we come back online will re-create the provisioned images back again. We will also update vSphere while at it. Regards, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Mon Mar 6 05:00:09 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Mon, 6 Mar 2017 04:00:09 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <5098997.BicRX6s0W7@tjmaciei-mobl1> <14519401487447368@web10g.yandex.ru> <18144646.GrGa0AsBTG@tjmaciei-mobl1> <36e680d8-b506-a361-d845-3613b0d902cd@kdab.com> Message-ID: <211DD88F-22C8-46F4-B572-C9833ACC07C5@qt.io> Hi Kevin, As has been said many times, features of Qt 5.9 have already been developed and frozen, development of Qt 5.10 features is ongoing. Postponing or reopening Qt 5.9 would mean we work very inefficiently and that should be avoided. There are also many other reasons, as I have explained in multiple mails to the mailing lists. No-one likes skipping patch level releases, but this is what now needs to be done. Qt 5.7.1 has been released in December and Qt 5.8.0 in January – so we do have very recent two releases you and others to use. What comes to Open Governance, we of course can always improve communications. What was done is that I informed decision that The Qt Company had done not to participate in making Qt 5.8.1 release and based on that the Release team of the Qt Project decided to close Qt 5.8 branch. Some people volunteered to help in making Qt 5.8.1, which is great but... the current infrastructure does not enable making a new patch release without a significant effort from The Qt Company personnel as well as a major load in the systems. Therefore, I have proposed that we all rather focus on getting Qt 5.9.0 and 5.9.1 out faster and improve the stability of the infrastructure (including fixing the flaky test cases). We have many users still in Qt 5.6 LTS, which is fine, but eventually we need to provide new releases that receive more than one patch level release. Hopefully we can do this for Qt 5.9 with the new CI system infrastructure coming around June timeframe as well as the improve stability of the system achieved via fixing the flaky cases. Yours, Tuukka On 04/03/2017, 0.56, "Development on behalf of Kevin Kofler" wrote: Mathias Hasselmann wrote: > Guys, by not delivering bugfix releases for arbitrary reasons we are > risking to kill Qt's credibility as reliable toolkit. Our users trust in > getting bugfix releases. I agree with this. I really don't see why you don't postpone 5.9 instead. Qt used to release on a 9 to 12 month basis, now it is down to 6 months. And for 5.9, not even that, because somehow there is an unrealistic expectation that 5.9 magically makes up for the delays in releasing 5.8. The release schedule for 5.9 should be based on the actual 5.8 release date, not the planned 5.8 release date. The amount of churn is such that some distros are still working on packaging 5.8 while you are already about to branch 5.9. I also agree with Marc Mutz (and no, you have not misread ;-) ) that the way the decision is being dictated onto the community runs counter to the "Open Governance" promises. Kevin Kofler _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From egor.pugin at gmail.com Mon Mar 6 21:25:48 2017 From: egor.pugin at gmail.com (Egor Pugin) Date: Mon, 6 Mar 2017 23:25:48 +0300 Subject: [Development] syncqt.pl in C++ Message-ID: Hi, I'm experimenting with own builds of qt and found that raw sources in git repo (e.g. [1]) do not contain include dir. It is created by bin/syncqt.pl, so we have a perl dependency. On later steps qt is built pretty good without any serious issues. Is there any attempts to rewrite syncqt.pl in c++? Maybe someone, who tried to perform cmake-based build of qt, investigated this question? Could it be useful at all? [1] http://code.qt.io/cgit/qt/qtbase.git/tree/ -- Egor Pugin From thiago.macieira at intel.com Mon Mar 6 22:51:00 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 06 Mar 2017 22:51:00 +0100 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: Message-ID: <2785097.kyDibWfl1L@tjmaciei-mobl1> Em segunda-feira, 6 de março de 2017, às 21:25:48 CET, Egor Pugin escreveu: > Hi, > > I'm experimenting with own builds of qt and found that raw sources in > git repo (e.g. [1]) do not contain include dir. It is created by > bin/syncqt.pl, so we have a perl dependency. Yes, we do. We've had that dependency for 15 years. > On later steps qt is built pretty good without any serious issues. > > Is there any attempts to rewrite syncqt.pl in c++? No. > Maybe someone, who tried to perform cmake-based build of qt, > investigated this question? > Could it be useful at all? I don't think we'll accept it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at qt.io Mon Mar 6 23:32:42 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Mon, 6 Mar 2017 22:32:42 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: <2785097.kyDibWfl1L@tjmaciei-mobl1> References: <2785097.kyDibWfl1L@tjmaciei-mobl1> Message-ID: > On Mar 6, 2017, at 1:51 PM, Thiago Macieira wrote: > > Em segunda-feira, 6 de março de 2017, às 21:25:48 CET, Egor Pugin escreveu: >> Hi, >> >> I'm experimenting with own builds of qt and found that raw sources in >> git repo (e.g. [1]) do not contain include dir. It is created by >> bin/syncqt.pl, so we have a perl dependency. > > Yes, we do. We've had that dependency for 15 years. And it will go away once Qt moves to Qbs as its default build system in Qt 6. > >> On later steps qt is built pretty good without any serious issues. >> >> Is there any attempts to rewrite syncqt.pl in c++? > > No. It will be "rewritten" (although the replacement will not be a direct translation) in JavaScript when Qt moves to Qbs. > >> Maybe someone, who tried to perform cmake-based build of qt, >> investigated this question? >> Could it be useful at all? > > I don't think we'll accept it. No, we won't. Qbs. ;) > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From egor.pugin at gmail.com Mon Mar 6 23:47:17 2017 From: egor.pugin at gmail.com (Egor Pugin) Date: Tue, 7 Mar 2017 01:47:17 +0300 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: <2785097.kyDibWfl1L@tjmaciei-mobl1> Message-ID: I see. Thanks. On 7 March 2017 at 01:32, Jake Petroules wrote: > >> On Mar 6, 2017, at 1:51 PM, Thiago Macieira wrote: >> >> Em segunda-feira, 6 de março de 2017, às 21:25:48 CET, Egor Pugin escreveu: >>> Hi, >>> >>> I'm experimenting with own builds of qt and found that raw sources in >>> git repo (e.g. [1]) do not contain include dir. It is created by >>> bin/syncqt.pl, so we have a perl dependency. >> >> Yes, we do. We've had that dependency for 15 years. > > And it will go away once Qt moves to Qbs as its default build system in Qt 6. > >> >>> On later steps qt is built pretty good without any serious issues. >>> >>> Is there any attempts to rewrite syncqt.pl in c++? >> >> No. > > It will be "rewritten" (although the replacement will not be a direct translation) in JavaScript when Qt moves to Qbs. > >> >>> Maybe someone, who tried to perform cmake-based build of qt, >>> investigated this question? >>> Could it be useful at all? >> >> I don't think we'll accept it. > > No, we won't. Qbs. ;) > >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Jake Petroules - jake.petroules at qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Egor Pugin From thiago.macieira at intel.com Mon Mar 6 23:59:11 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 06 Mar 2017 23:59:11 +0100 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: <2785097.kyDibWfl1L@tjmaciei-mobl1> Message-ID: <5357767.Bo3xEg3dNL@tjmaciei-mobl1> Em segunda-feira, 6 de março de 2017, às 23:32:42 CET, Jake Petroules escreveu: > > Yes, we do. We've had that dependency for 15 years. > > And it will go away once Qt moves to Qbs as its default build system in Qt > 6. There has been no discussion of qbs. Therefore, there is no decision on what ot use for Qt 6. It might be cmake or qmake. But if we do use a tool that is not part of Qt's sources, it would be nice to use one that does support generating the headers. I don't find it likely to find a generator that will allow the powerful scanning that syncqt.pl does, unless like syncqt.pl it is actually a fully-featured language with an extensive library. Like Scons (which I'd hate to use, but at this point it is a contender just as likely). > >> On later steps qt is built pretty good without any serious issues. > >> > >> Is there any attempts to rewrite syncqt.pl in c++? > > > > No. > > > It will be "rewritten" (although the replacement will not be a direct > translation) in JavaScript when Qt moves to Qbs. Or a cmake script or a Python routine in Scons. Or left as-is. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at qt.io Tue Mar 7 08:16:14 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 7 Mar 2017 07:16:14 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: <5357767.Bo3xEg3dNL@tjmaciei-mobl1> References: <2785097.kyDibWfl1L@tjmaciei-mobl1> , <5357767.Bo3xEg3dNL@tjmaciei-mobl1> Message-ID: <922C5F2D-EA4C-46EA-957A-CD281D0AFF3A@qt.io> Hi, I for one would welcome a C++ rewrite of syncqt inside qmake to get rid of the perl dependency. However I do not have the authority to approve such a contribution. It is something we have talked about many times on the hallway. Until we arrive in the promised land of a new build system, it would allow us to simplify our source packaging even further the moment we have it (syncqt C++). Simon > On 7 Mar 2017, at 08:11, Thiago Macieira wrote: > > Em segunda-feira, 6 de março de 2017, às 23:32:42 CET, Jake Petroules > escreveu: >>> Yes, we do. We've had that dependency for 15 years. >> >> And it will go away once Qt moves to Qbs as its default build system in Qt >> 6. > > There has been no discussion of qbs. Therefore, there is no decision on what > ot use for Qt 6. It might be cmake or qmake. > > But if we do use a tool that is not part of Qt's sources, it would be nice to > use one that does support generating the headers. I don't find it likely to find > a generator that will allow the powerful scanning that syncqt.pl does, unless > like syncqt.pl it is actually a fully-featured language with an extensive > library. > > Like Scons (which I'd hate to use, but at this point it is a contender just as > likely). > >>>> On later steps qt is built pretty good without any serious issues. >>>> >>>> Is there any attempts to rewrite syncqt.pl in c++? >>> >>> No. >> >> >> It will be "rewritten" (although the replacement will not be a direct >> translation) in JavaScript when Qt moves to Qbs. > > Or a cmake script or a Python routine in Scons. > > Or left as-is. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue Mar 7 11:46:58 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 07 Mar 2017 11:46:58 +0100 Subject: [Development] syncqt.pl in C++ In-Reply-To: <922C5F2D-EA4C-46EA-957A-CD281D0AFF3A@qt.io> References: <5357767.Bo3xEg3dNL@tjmaciei-mobl1> <922C5F2D-EA4C-46EA-957A-CD281D0AFF3A@qt.io> Message-ID: <1840274.Il0Y8UKPlW@tjmaciei-mobl1> Em terça-feira, 7 de março de 2017, às 08:16:14 CET, Simon Hausmann escreveu: > Hi, > > I for one would welcome a C++ rewrite of syncqt inside qmake to get rid of > the perl dependency. However I do not have the authority to approve such a > contribution. It is something we have talked about many times on the > hallway. You have a chicken-and-the-egg problem here, as qmake depends on the headers being generated by syncqt before it can be compiled. I read the OP's email as a request to write it in non-Qt C++ so we could drop the Perl dependency. I don't think we want that, it's not worth the effort. > Until we arrive in the promised land of a new build system, it would allow > us to simplify our source packaging even further the moment we have it > (syncqt C++). syncqt in qmake, yes, possibly. Rewrite it in non-Qt C++, please no. > > But if we do use a tool that is not part of Qt's sources, it would be nice > > to use one that does support generating the headers. I don't find it > > likely to find a generator that will allow the powerful scanning that > > syncqt.pl does, unless like syncqt.pl it is actually a fully-featured > > language with an extensive library. > > > > Like Scons (which I'd hate to use, but at this point it is a contender > > just as likely). Actually, rephrasing: Scons could be a contender, but it's not "just as likely" because no one in the Qt community has experience with it. It's actually quite unlikely. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From a.volkov at rusbitech.ru Tue Mar 7 11:57:03 2017 From: a.volkov at rusbitech.ru (Alexander Volkov) Date: Tue, 7 Mar 2017 13:57:03 +0300 Subject: [Development] Comparison of version numbers in qmake project files Message-ID: <78269170-fb0c-20b4-83dd-4485c2c75f4e@rusbitech.ru> Hi, Need more reviewers for https://codereview.qt-project.org/#/c/181665/ which adds test functions for comparing version numbers: versionNumberAtLeast(VERSION, 5.10.0) { ... } versionNumberLessThan(VERSION, 5.10.0) { ... } There are two questions: 1. Whether to use Number in the functions' names? (versionNumberAtLeast vs versionAtLeast) 2. Is it enough to add only one function (version[Number]AtLeast)? BR, Alexander. From annulen at yandex.ru Tue Mar 7 12:52:51 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 07 Mar 2017 14:52:51 +0300 Subject: [Development] Comparison of version numbers in qmake project files In-Reply-To: <78269170-fb0c-20b4-83dd-4485c2c75f4e@rusbitech.ru> References: <78269170-fb0c-20b4-83dd-4485c2c75f4e@rusbitech.ru> Message-ID: <4687301488887571@web6o.yandex.ru> 07.03.2017, 13:54, "Alexander Volkov" : > Hi, > > Need more reviewers for https://codereview.qt-project.org/#/c/181665/ > which adds test functions for comparing version numbers: > > versionNumberAtLeast(VERSION, 5.10.0) { >      ... > } > > versionNumberLessThan(VERSION, 5.10.0) { >      ... > } Wow, it happened! > > There are two questions: > > 1. Whether to use Number in the functions' names? (versionNumberAtLeast > vs versionAtLeast) > > 2. Is it enough to add only one function (version[Number]AtLeast)? > > BR, > Alexander. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From rjvbertin at gmail.com Tue Mar 7 14:04:58 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 07 Mar 2017 14:04:58 +0100 Subject: [Development] QProcess fork() failure and overcommit Message-ID: <1805273.EBMQupCyU0@portia.local> Hi, I have a bit of an intriguing issue I hope someone here could help me understand. If not, sorry for the noise. I'm seeing occasional QProcess failures where QProcess:waitForStarted() fails and gives rise to errors like kdevplatform.vcs: "DVCSJob::start: git ls-files -- kclock.cpp failed to start: Resource error (fork failure): Cannot allocate memory" Those come and go in episodes; restarting the affected application always helped too (for a while). Last time this happened htop reported I had 6955Mb used of 7899Mb, and not even 10% swap used (1151Mb of 16Gb) but despite that the issue went away when I turned overcommit back on (I usually run with overcommit_memory=2 and overcommit_ratio=80). This only happened to me with KDevelop5 until now, i.e. a Qt5/KF5 based application, running on a KDE4 (= Qt4-based) desktop. If memory contention were really the cause here I would expect to see traces of similar failures elsewhere too because KDevelop isn't exactly the only KDE application that makes generous use of QProcess. Is there anything in QProces (Qt5) vs. the Qt4 version that could explain fork() failing, or else can it be the way QProcess is being used which causes this in KDevelop but not other applications? FWIW, not only do I see this in KDevelop exclusively, I've also seen it only when executing git commands through QProcess. I've been seeing this for several months now, meaning with Qt 5.6.2, 5.7.1 and now 5.8.0 and kernels 4.7, 4.9 and possibly 4.5.7 (all with Con Kolivas's patches). Thanks, René From schnitzeltony at googlemail.com Tue Mar 7 14:22:23 2017 From: schnitzeltony at googlemail.com (=?UTF-8?Q?Andreas_M=C3=BCller?=) Date: Tue, 7 Mar 2017 14:22:23 +0100 Subject: [Development] Qt5.8 qdbuscpp2xml broken for kde baloo? In-Reply-To: References: Message-ID: On Fri, Feb 10, 2017 at 11:19 AM, Andreas Müller wrote: > Hi, > > I am cross building Qt and KDE with yocto environment. After Update to > Qt 5.8 the package baloo from KDE KF5 is broken. After investigation I > found that qdbuscpp2xml 5.8 build misses some public slots. > > I get for Qt5.8 build by yocto: > > qdbuscpp2xml -a filecontentindexer.h > Unregistered input type in parameter list: QDBusMessage > Unregistered input type in parameter list: QDBusMessage > 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd"> > > > > > > > > > > > > > On my local fedora Qt5.7.1 > qdbuscpp2xml -a filecontentindexer.h > 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd"> > > > > > > > > > > > > > > > > > You can see that qdbuscpp2xml complains for unregistered QDBusMessage > and the slots 'registerMonitor' and 'unregisterMonitor' having > QDBusMessage in parameter are missing. > > Since yocto builds also native qdbuscpp2xml it might be possible that > there is something missing for qdbuscpp2xml. > > Pointers how to get around or even confirmation of a bug are welcome - > baloo's filecontentindexer.h is attached > Coming back to the original qdbuscpp2xml / baloo problem: I have checked further and think to know what happened: * qdbuscpp2xml build based on Qt5.7 simply ignored QDBusMessage parameters. This seemed to be silently accepted by baloo as the call to unregisterMonitor was done without parameters [1]. * qdbuscpp2xml build based on Qt5.8 bootstrapped complained with 'Unregistered input type in parameter list: QDBusMessage' and ignoring registerMonitor/unregisterMonitor as mentioned above. * qdbuscpp2xml build based on Qt5.8 and patched (attachment) to non-bootstrapped handles QDBusMessage properly. I dropped a note a kde-devel either but can not find it in any archive. Anyway I can hacked baloo to build now and am happy. [1] https://cgit.kde.org/baloo.git/tree/src/qml/experimental/monitor.cpp#n114 Andreas From schnitzeltony at googlemail.com Tue Mar 7 14:24:39 2017 From: schnitzeltony at googlemail.com (=?UTF-8?Q?Andreas_M=C3=BCller?=) Date: Tue, 7 Mar 2017 14:24:39 +0100 Subject: [Development] Qt5.8 qdbuscpp2xml broken for kde baloo? In-Reply-To: References: Message-ID: On Tue, Mar 7, 2017 at 2:22 PM, Andreas Müller wrote: > On Fri, Feb 10, 2017 at 11:19 AM, Andreas Müller > wrote: >> Hi, >> >> I am cross building Qt and KDE with yocto environment. After Update to >> Qt 5.8 the package baloo from KDE KF5 is broken. After investigation I >> found that qdbuscpp2xml 5.8 build misses some public slots. >> >> I get for Qt5.8 build by yocto: >> >> qdbuscpp2xml -a filecontentindexer.h >> Unregistered input type in parameter list: QDBusMessage >> Unregistered input type in parameter list: QDBusMessage >> > 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd"> >> >> >> >> >> >> >> >> >> >> >> >> >> On my local fedora Qt5.7.1 >> qdbuscpp2xml -a filecontentindexer.h >> > 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd"> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> You can see that qdbuscpp2xml complains for unregistered QDBusMessage >> and the slots 'registerMonitor' and 'unregisterMonitor' having >> QDBusMessage in parameter are missing. >> >> Since yocto builds also native qdbuscpp2xml it might be possible that >> there is something missing for qdbuscpp2xml. >> >> Pointers how to get around or even confirmation of a bug are welcome - >> baloo's filecontentindexer.h is attached >> > Coming back to the original qdbuscpp2xml / baloo problem: I have > checked further and think to know what happened: > > * qdbuscpp2xml build based on Qt5.7 simply ignored QDBusMessage > parameters. This seemed to be silently accepted by baloo as the call > to unregisterMonitor was done without parameters [1]. > * qdbuscpp2xml build based on Qt5.8 bootstrapped complained with > 'Unregistered input type in parameter list: QDBusMessage' and ignoring > registerMonitor/unregisterMonitor as mentioned above. > * qdbuscpp2xml build based on Qt5.8 and patched (attachment) to > non-bootstrapped handles QDBusMessage properly. > > I dropped a note a kde-devel either but can not find it in any > archive. Anyway I can hacked baloo to build now and am happy. > > [1] https://cgit.kde.org/baloo.git/tree/src/qml/experimental/monitor.cpp#n114 > Forgot attachment Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: 0012-qdbuscpp2xml.pro-do-not-build-with-bootstrapped-depe.patch Type: text/x-patch Size: 2752 bytes Desc: not available URL: From christian.kandeler at qt.io Tue Mar 7 14:32:13 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Tue, 7 Mar 2017 14:32:13 +0100 Subject: [Development] QProcess fork() failure and overcommit In-Reply-To: <1805273.EBMQupCyU0@portia.local> References: <1805273.EBMQupCyU0@portia.local> Message-ID: <2435c6af-d8a7-bfd5-3f2b-a29479400357@qt.io> On 03/07/2017 02:04 PM, René J.V. Bertin wrote: > I have a bit of an intriguing issue I hope someone here could help me understand. If not, sorry for the noise. > > I'm seeing occasional QProcess failures where QProcess:waitForStarted() fails and gives rise to errors like > > kdevplatform.vcs: "DVCSJob::start: git ls-files -- kclock.cpp failed to start: Resource error (fork failure): Cannot allocate memory" > > Those come and go in episodes; restarting the affected application always helped too (for a while). > > Last time this happened htop reported I had 6955Mb used of 7899Mb, and not even 10% swap used (1151Mb of 16Gb) but despite that the issue went away when I turned overcommit back on (I usually run with overcommit_memory=2 and overcommit_ratio=80). > > This only happened to me with KDevelop5 until now, i.e. a Qt5/KF5 based application, running on a KDE4 (= Qt4-based) desktop. > If memory contention were really the cause here I would expect to see traces of similar failures elsewhere too because KDevelop isn't exactly the only KDE application that makes generous use of QProcess. > > Is there anything in QProces (Qt5) vs. the Qt4 version that could explain fork() failing, or else can it be the way QProcess is being used which causes this in KDevelop but not other applications? This kind of stuff seems to happen when the parent process has allocated a lot of memory. I haven't debugged into it, but one idea might be that the page tables themselves get to a non-trivial size and thus copying them causes allocation problems. Note also that starting a QProcess becomes enormously slow in such applications; for instance, on my machine here, I can only start about 20 processes per second from an application that has 1 GB of memory allocated. Christian From rjvbertin at gmail.com Tue Mar 7 14:54:29 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Tue, 07 Mar 2017 14:54:29 +0100 Subject: [Development] QProcess fork() failure and overcommit References: <1805273.EBMQupCyU0@portia.local> <2435c6af-d8a7-bfd5-3f2b-a29479400357@qt.io> Message-ID: <57270526.MUzU2Prna3@patux.local> Christian Kandeler wrote: > This kind of stuff seems to happen when the parent process has allocated > a lot of memory. I haven't debugged into it, but one idea might be that What is a lot here? Typical usage for one of the KDevelop sessions that tends to be affected is around 70Mb total according to KSysGuard. Hardly a value that shocks me... > the page tables themselves get to a non-trivial size and thus copying > them causes allocation problems. Something application-specific thus? That would fit with the observation that not all KDevelop sessions are always affected at the same time. > Note also that starting a QProcess becomes enormously slow in such > applications; for instance, on my machine here, I can only start about > 20 processes per second from an application that has 1 GB of memory > allocated. As opposed to how many from a leaner application? R. From christian.kandeler at qt.io Tue Mar 7 15:10:30 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Tue, 7 Mar 2017 15:10:30 +0100 Subject: [Development] QProcess fork() failure and overcommit In-Reply-To: <57270526.MUzU2Prna3@patux.local> References: <1805273.EBMQupCyU0@portia.local> <2435c6af-d8a7-bfd5-3f2b-a29479400357@qt.io> <57270526.MUzU2Prna3@patux.local> Message-ID: <2f438e84-6d1d-096f-3dc9-fa27afb069a4@qt.io> On 03/07/2017 02:54 PM, René J. V. Bertin wrote: >> This kind of stuff seems to happen when the parent process has allocated >> a lot of memory. I haven't debugged into it, but one idea might be that > > What is a lot here? Typical usage for one of the KDevelop sessions that tends to > be affected is around 70Mb total according to KSysGuard. Hardly a value that > shocks me... More than that. Let's say a Gig, as in my example. >> Note also that starting a QProcess becomes enormously slow in such >> applications; for instance, on my machine here, I can only start about >> 20 processes per second from an application that has 1 GB of memory >> allocated. > > As opposed to how many from a leaner application? Hundreds. Christian From Simon.Hausmann at qt.io Tue Mar 7 15:20:18 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 7 Mar 2017 14:20:18 +0000 Subject: [Development] QProcess fork() failure and overcommit In-Reply-To: <1805273.EBMQupCyU0@portia.local> References: <1805273.EBMQupCyU0@portia.local> Message-ID: Hi, It would be interesting to see /proc//maps of the KDevelop process when fork fails. I would imagine - like Christian - that there is a shortage of memory mappings. It's odd that this is an issue, as there shouldn't be big memory mappings _usually_. But for example if KDevelop ends up using QtScript and you're on a 64-bit system, then we end up allocating 2GB of address space, which the kernel has to copy (in terms of page tables) when forking. It could be that you're short of that. We should probably mark these address spaces with MADV_DONTFORK. But can you check first if KDevelop ends up using QtScript by chance? Simon ________________________________ From: Development on behalf of René J.V. Bertin Sent: Tuesday, March 7, 2017 2:04:58 PM To: development at qt-project.org Subject: [Development] QProcess fork() failure and overcommit Hi, I have a bit of an intriguing issue I hope someone here could help me understand. If not, sorry for the noise. I'm seeing occasional QProcess failures where QProcess:waitForStarted() fails and gives rise to errors like kdevplatform.vcs: "DVCSJob::start: git ls-files -- kclock.cpp failed to start: Resource error (fork failure): Cannot allocate memory" Those come and go in episodes; restarting the affected application always helped too (for a while). Last time this happened htop reported I had 6955Mb used of 7899Mb, and not even 10% swap used (1151Mb of 16Gb) but despite that the issue went away when I turned overcommit back on (I usually run with overcommit_memory=2 and overcommit_ratio=80). This only happened to me with KDevelop5 until now, i.e. a Qt5/KF5 based application, running on a KDE4 (= Qt4-based) desktop. If memory contention were really the cause here I would expect to see traces of similar failures elsewhere too because KDevelop isn't exactly the only KDE application that makes generous use of QProcess. Is there anything in QProces (Qt5) vs. the Qt4 version that could explain fork() failing, or else can it be the way QProcess is being used which causes this in KDevelop but not other applications? FWIW, not only do I see this in KDevelop exclusively, I've also seen it only when executing git commands through QProcess. I've been seeing this for several months now, meaning with Qt 5.6.2, 5.7.1 and now 5.8.0 and kernels 4.7, 4.9 and possibly 4.5.7 (all with Con Kolivas's patches). Thanks, René _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Tue Mar 7 16:42:31 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 07 Mar 2017 16:42:31 +0100 Subject: [Development] QProcess fork() failure and overcommit In-Reply-To: References: <1805273.EBMQupCyU0@portia.local> Message-ID: <4792819.XUJDhIzVCV@bola> On Tuesday March 7 2017 14:20:18 Simon Hausmann wrote: Hi > But for example if KDevelop ends up using QtScript and you're on a 64-bit system, then we end up allocating 2GB of address space, which the kernel has to copy (in terms of page tables) when forking. It could be that you're short of that. That could be, but if my understanding of overcommit_memory=2 is correct I should still have enough margin for even that. Unless there's an additional per-process limit that comes into play? >We should probably mark these address spaces with MADV_DONTFORK. I suppose I could test such a change, if that helps. >But can you check first if KDevelop ends up using QtScript by chance? The CMake project manager appears to use QScript for evaluating math expressions but even a session that doesn't load the corresponding plugin ends up loading the QtScript library according to its /proc/.../maps file. If Kevin picks up on this thread he may be able to say more about the paths through which KDevelop ends up using QtScript. %> fgrep -i 5script /proc/24536/maps 7fd00cc9e000-7fd00cef5000 r-xp 00000000 00:27 37325 /opt/local/libexec/qt5/lib/libQt5Script.so.5.8.0 7fd00cef5000-7fd00d0f5000 ---p 00257000 00:27 37325 /opt/local/libexec/qt5/lib/libQt5Script.so.5.8.0 7fd00d0f5000-7fd00d107000 r--p 00257000 00:27 37325 /opt/local/libexec/qt5/lib/libQt5Script.so.5.8.0 7fd00d107000-7fd00d109000 rw-p 00269000 00:27 37325 /opt/local/libexec/qt5/lib/libQt5Script.so.5.8.0 R. From kfunk at kde.org Tue Mar 7 17:29:54 2017 From: kfunk at kde.org (Kevin Funk) Date: Tue, 07 Mar 2017 17:29:54 +0100 Subject: [Development] QProcess fork() failure and overcommit In-Reply-To: <4792819.XUJDhIzVCV@bola> References: <1805273.EBMQupCyU0@portia.local> <4792819.XUJDhIzVCV@bola> Message-ID: <2206946.pQ9Pcv2lim@kerberos> On Tuesday, 7 March 2017 16:42:31 CET René J.V. Bertin wrote: > On Tuesday March 7 2017 14:20:18 Simon Hausmann wrote: > Hi > > > But for example if KDevelop ends up using QtScript and you're on a 64-bit > > system, then we end up allocating 2GB of address space, which the kernel > > has to copy (in terms of page tables) when forking. It could be that > > you're short of that. > That could be, but if my understanding of overcommit_memory=2 is correct I > should still have enough margin for even that. Unless there's an additional > per-process limit that comes into play? > >We should probably mark these address spaces with MADV_DONTFORK. > > I suppose I could test such a change, if that helps. > > >But can you check first if KDevelop ends up using QtScript by chance? > > The CMake project manager appears to use QScript for evaluating math > expressions but even a session that doesn't load the corresponding plugin > ends up loading the QtScript library according to its /proc/.../maps file. > If Kevin picks up on this thread he may be able to say more about the paths > through which KDevelop ends up using QtScript. Here it is: % lddtree .../libKDevPlatformShell.so (snip) libKDevPlatformLanguage.so.10 => .../libKDevPlatformLanguage.so.10 libGrantlee_Templates.so.5 => .../libGrantlee_Templates.so.5 libQt5Script.so.5 => .../libQt5Script.so.5 It's pulled in by the Grantlee library. KF5::TextEditor depends on Qt5::Script as well. Regards, Kevin > %> fgrep -i 5script /proc/24536/maps > 7fd00cc9e000-7fd00cef5000 r-xp 00000000 00:27 37325 > /opt/local/libexec/qt5/lib/libQt5Script.so.5.8.0 7fd00cef5000-7fd00d0f5000 > ---p 00257000 00:27 37325 > /opt/local/libexec/qt5/lib/libQt5Script.so.5.8.0 7fd00d0f5000-7fd00d107000 > r--p 00257000 00:27 37325 > /opt/local/libexec/qt5/lib/libQt5Script.so.5.8.0 7fd00d107000-7fd00d109000 > rw-p 00269000 00:27 37325 > /opt/local/libexec/qt5/lib/libQt5Script.so.5.8.0 > > R. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Kevin Funk | kfunk at kde.org | http://kfunk.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: This is a digitally signed message part. URL: From Wolfgang.Baron at gmx.net Tue Mar 7 17:47:24 2017 From: Wolfgang.Baron at gmx.net (Wolfgang Baron) Date: Tue, 7 Mar 2017 17:47:24 +0100 Subject: [Development] syncqt.pl in C++ Message-ID: On 7 Mar 2017, at 08:11, Thiago Macieira wrote: > There has been no discussion of qbs. Therefore, there is no > decision on what to use for Qt 6. It might be cmake or qmake. Then please start that discussion now. Qbs is a secret weapon for all developers trying to do test driven development but fighting long turn around times in large projects. However, the lack of inside determination to feature Qbs as the primary make system has stalled the acceptance and development of Qbs. Qbs is a great improvement but lacks appropriate documentation, context sensitive help and first class support in Qt-Creator (yes, and there may a little bug here or there). An official statement by the Qt Company would greatly improve the willingness of the developer community to use and improve Qbs. Please make that decision ASAP, so we can all enjoy the best make system ever soon! Kind regards, Wolfgang -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Tue Mar 7 17:53:41 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 07 Mar 2017 17:53:41 +0100 Subject: [Development] QProcess fork() failure and overcommit In-Reply-To: <2206946.pQ9Pcv2lim@kerberos> References: <1805273.EBMQupCyU0@portia.local> <4792819.XUJDhIzVCV@bola> <2206946.pQ9Pcv2lim@kerberos> Message-ID: <13254176.C6KrK6M3W4@portia.local> On Tuesday March 07 2017 17:29:54 Kevin Funk wrote: > It's pulled in by the Grantlee library. KF5::TextEditor depends on Qt5::Script > as well. There you have it, thanks Kevin. One tends to forget (I do at least) that spawning a little helper process can be quite expensive, sometimes prohibitively so. Makes you wonder what kind of cross-platform alternatives there are! R From Jake.Petroules at qt.io Tue Mar 7 19:19:12 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 7 Mar 2017 18:19:12 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: Message-ID: <8A57E41C-3CF5-46E7-9622-CE5E8BB6C268@qt.io> > On Mar 7, 2017, at 8:47 AM, Wolfgang Baron wrote: > > On 7 Mar 2017, at 08:11, Thiago Macieira > wrote: > > > There has been no discussion of qbs. Therefore, there is no > > decision on what to use for Qt 6. It might be cmake or qmake. > > Then please start that discussion now. Qbs is a secret weapon for all developers trying to do test driven development but fighting long turn around times in large projects. However, the lack of inside determination to feature Qbs as the primary make system has stalled the acceptance and development of Qbs. Qbs is a great improvement but lacks appropriate documentation, Please... file bug reports with what you think is missing. We feel that we're already doing a far better job than we did with qmake and want to make sure that Qbs has great documentation as it is very critical. I also do my best to make sure all qbs related questions on Stack Overflow are answered. > context sensitive help and first class support in Qt-Creator (yes, and there may a little bug here or there). An official statement by the Qt Company would greatly improve the willingness of the developer community to use and improve Qbs. > > Please make that decision ASAP, so we can all enjoy the best make system ever soon! Let me clarify: internally at The Qt Company we made the decision that Qbs will become the default build system for Qt 6. Technically the Qt Project has not yet made that decision but once the formalities are gone through, we will almost inevitably come to the same conclusion. > > Kind regards, > > Wolfgang > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From lars.knoll at qt.io Tue Mar 7 20:12:24 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 7 Mar 2017 19:12:24 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: Message-ID: Hi, Thiago's right that there has not been a formal decision in the Qt project about the build system to use for Qt 6. So saying qbs will be the build system for Qt 6 is getting a bit ahead of things. But we have had many discussions in the past as well, where the result was that the people maintaining the Qt build system would like to see us using qbs instead of qmake as the Qt build system in the future. This never lead anywhere, as this would have required quite some work to implement the functionality required in qbs. The Qt Company has now very recently made a decision to now go and invest the man power required to turn qbs into a product we can fully support in the future. This decision comes from the fact that we see that build systems are a very integral part of the developer experience, and it's one of the areas where we see that there still is a large potential for improvement. qbs is promising to bring that improvement to us and our users. This also makes qbs a natural choice to also use for Qt itself, and I believe all the people that have worked and maintained Qt's build system over the last few years are supporting this. Of course this requires that we can show that qbs can be used to build Qt. Cheers, Lars On 7 Mar 2017, at 17:47, Wolfgang Baron > wrote: On 7 Mar 2017, at 08:11, Thiago Macieira wrote: > There has been no discussion of qbs. Therefore, there is no > decision on what to use for Qt 6. It might be cmake or qmake. Then please start that discussion now. Qbs is a secret weapon for all developers trying to do test driven development but fighting long turn around times in large projects. However, the lack of inside determination to feature Qbs as the primary make system has stalled the acceptance and development of Qbs. Qbs is a great improvement but lacks appropriate documentation, context sensitive help and first class support in Qt-Creator (yes, and there may a little bug here or there). An official statement by the Qt Company would greatly improve the willingness of the developer community to use and improve Qbs. Please make that decision ASAP, so we can all enjoy the best make system ever soon! Kind regards, Wolfgang _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich at kde.org Tue Mar 7 21:37:46 2017 From: rich at kde.org (Richard Moore) Date: Tue, 7 Mar 2017 20:37:46 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: Message-ID: On 7 March 2017 at 19:12, Lars Knoll wrote: > Hi, > > Thiago's right that there has not been a formal decision in the Qt project > about the build system to use for Qt 6. So saying qbs will be the build > system for Qt 6 is getting a bit ahead of things. > > But we have had many discussions in the past as well, where the result was > that the people maintaining the Qt build system would like to see us using > qbs instead of qmake as the Qt build system in the future. This never lead > anywhere, as this would have required quite some work to implement the > functionality required in qbs. > > The Qt Company has now very recently made a decision to now go and invest > the man power required to turn qbs into a product we can fully support in > the future. This decision comes from the fact that we see that build > systems are a very integral part of the developer experience, and it's one > of the areas where we see that there still is a large potential for > improvement. qbs is promising to bring that improvement to us and our users. > > ​Pretty depressing since the discussions at the developer summit seemed to conclude the exact opposite.​ I wish those developers were working on something more useful than a new wheel. Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Mar 7 21:49:44 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 07 Mar 2017 21:49:44 +0100 Subject: [Development] syncqt.pl in C++ In-Reply-To: <8A57E41C-3CF5-46E7-9622-CE5E8BB6C268@qt.io> References: <8A57E41C-3CF5-46E7-9622-CE5E8BB6C268@qt.io> Message-ID: <12410273.vzv0k9FGSq@tjmaciei-mobl1> Em terça-feira, 7 de março de 2017, às 19:19:12 CET, Jake Petroules escreveu: > Let me clarify: internally at The Qt Company we made the decision that Qbs > will become the default build system for Qt 6. Technically the Qt Project > has not yet made that decision but once the formalities are gone through, > we will almost inevitably come to the same conclusion. What matters is that the Qt Project has not decided, so it's not decided. Period. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Mar 7 21:54:23 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 07 Mar 2017 21:54:23 +0100 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: Message-ID: <1733911.qi4zXjP78C@tjmaciei-mobl1> Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard Moore escreveu: > > The Qt Company has now very recently made a decision to now go and invest > > the man power required to turn qbs into a product we can fully support in > > the future. This decision comes from the fact that we see that build > > systems are a very integral part of the developer experience, and it's one > > of the areas where we see that there still is a large potential for > > improvement. qbs is promising to bring that improvement to us and our > > users. > ​Pretty depressing since the discussions at the developer summit seemed to > conclude the exact opposite.​ I wish those developers were working on > something more useful than a new wheel. Same here, though I have also to concede that breaking the status quo (to quote Jake's tweet) is sometimes a good idea. Teambuilder -- to name another Trolltech project that had nothing to do with qt -- was a couple of orders of magnitude better than the tools that existed at the time (distcc). Icecream/ icecc came about only because TB wasn't open source, but every now and then I miss TB2 features that icecc doesn't have. TB3 would have been even better. Maybe qbs will be another such leapfrog. I can't fault TQtC for trying. But as I said, I agree with Richard and I can't help but feel that the effort could have been turned into making cmake even better, especially considering everyone[*] (including Microsoft!) is using it. [*] for some reason, the other project I work with (IoTivity) chose Scons. Ugh... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Mar 7 22:00:53 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 07 Mar 2017 22:00:53 +0100 Subject: [Development] QProcess fork() failure and overcommit In-Reply-To: <2435c6af-d8a7-bfd5-3f2b-a29479400357@qt.io> References: <1805273.EBMQupCyU0@portia.local> <2435c6af-d8a7-bfd5-3f2b-a29479400357@qt.io> Message-ID: <1593335.HAh8Yngdva@tjmaciei-mobl1> Em terça-feira, 7 de março de 2017, às 14:32:13 CET, Christian Kandeler escreveu: > This kind of stuff seems to happen when the parent process has allocated > a lot of memory. I haven't debugged into it, but one idea might be that > the page tables themselves get to a non-trivial size and thus copying > them causes allocation problems. > Note also that starting a QProcess becomes enormously slow in such > applications; for instance, on my machine here, I can only start about > 20 processes per second from an application that has 1 GB of memory > allocated. What OS is that? René was talking about macOS. Also, what's 1 GB for you? Virtual size or resident set size? The page table overhead in the OS shouldn't be more than a couple of megabytes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Mar 7 22:05:21 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 07 Mar 2017 22:05:21 +0100 Subject: [Development] QProcess fork() failure and overcommit In-Reply-To: <13254176.C6KrK6M3W4@portia.local> References: <1805273.EBMQupCyU0@portia.local> <2206946.pQ9Pcv2lim@kerberos> <13254176.C6KrK6M3W4@portia.local> Message-ID: <10562330.qO7P5klgjh@tjmaciei-mobl1> Em terça-feira, 7 de março de 2017, às 17:53:41 CET, René J.V. Bertin escreveu: > One tends to forget (I do at least) that spawning a little helper process > can be quite expensive, sometimes prohibitively so. Makes you wonder what > kind of cross-platform alternatives there are! It shouldn't be. fork() does need to copy the page tables and mark the pages as shared. It also means COW of certain pages. But the overhead shouldn't be that big. If anyone is seeing this, can you run your application with strace to get the timings? strace -T -e clone Add -f if the forking is happening outside the main thread. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Tue Mar 7 22:21:35 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 7 Mar 2017 21:21:35 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: <1733911.qi4zXjP78C@tjmaciei-mobl1> References: <1733911.qi4zXjP78C@tjmaciei-mobl1> Message-ID: <9A090E63-2A84-4C7E-B956-E1326388AC37@qt.io> > On 7 Mar 2017, at 21:54, Thiago Macieira wrote: > > Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard Moore escreveu: >>> The Qt Company has now very recently made a decision to now go and invest >>> the man power required to turn qbs into a product we can fully support in >>> the future. This decision comes from the fact that we see that build >>> systems are a very integral part of the developer experience, and it's one >>> of the areas where we see that there still is a large potential for >>> improvement. qbs is promising to bring that improvement to us and our >>> users. >> ​Pretty depressing since the discussions at the developer summit seemed to >> conclude the exact opposite.​ I wish those developers were working on >> something more useful than a new wheel. The discussions there were afai remember inconclusive. But the people that do the actual work on the build system were mostly positive towards qbs. > > Same here, though I have also to concede that breaking the status quo (to > quote Jake's tweet) is sometimes a good idea. Teambuilder -- to name another > Trolltech project that had nothing to do with qt -- was a couple of orders of > magnitude better than the tools that existed at the time (distcc). Icecream/ > icecc came about only because TB wasn't open source, but every now and then I > miss TB2 features that icecc doesn't have. TB3 would have been even better. > > Maybe qbs will be another such leapfrog. I can't fault TQtC for trying. That's what we believe. When we did the first version of Creator, everybody also thought we were nuts, and that we should rather integrate with Eclipse ;-) Cheers, Lars > > But as I said, I agree with Richard and I can't help but feel that the effort > could have been turned into making cmake even better, especially considering > everyone[*] (including Microsoft!) is using it. > > [*] for some reason, the other project I work with (IoTivity) chose Scons. > Ugh... > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From rich at kde.org Tue Mar 7 22:24:32 2017 From: rich at kde.org (Richard Moore) Date: Tue, 7 Mar 2017 21:24:32 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: <9A090E63-2A84-4C7E-B956-E1326388AC37@qt.io> References: <1733911.qi4zXjP78C@tjmaciei-mobl1> <9A090E63-2A84-4C7E-B956-E1326388AC37@qt.io> Message-ID: On 7 March 2017 at 21:21, Lars Knoll wrote: > > > On 7 Mar 2017, at 21:54, Thiago Macieira > wrote: > > > > Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard Moore > escreveu: > >>> The Qt Company has now very recently made a decision to now go and > invest > >>> the man power required to turn qbs into a product we can fully support > in > >>> the future. This decision comes from the fact that we see that build > >>> systems are a very integral part of the developer experience, and it's > one > >>> of the areas where we see that there still is a large potential for > >>> improvement. qbs is promising to bring that improvement to us and our > >>> users. > >> ​Pretty depressing since the discussions at the developer summit seemed > to > >> conclude the exact opposite.​ I wish those developers were working on > >> something more useful than a new wheel. > > The discussions there were afai remember inconclusive. But the people that > do the actual work on the build system were mostly positive towards qbs. > ​You didn't go to that session.​ Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Tue Mar 7 22:28:11 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 7 Mar 2017 21:28:11 +0000 Subject: [Development] QProcess fork() failure and overcommit In-Reply-To: <10562330.qO7P5klgjh@tjmaciei-mobl1> References: <1805273.EBMQupCyU0@portia.local> <2206946.pQ9Pcv2lim@kerberos> <13254176.C6KrK6M3W4@portia.local>, <10562330.qO7P5klgjh@tjmaciei-mobl1> Message-ID: <263AAAD9-8C89-440C-8EEF-83B7347E09D0@qt.io> I understand that this is in the context of Linux without overcommit. Simon > On 7 Mar 2017, at 22:05, Thiago Macieira wrote: > > Em terça-feira, 7 de março de 2017, às 17:53:41 CET, René J.V. Bertin > escreveu: >> One tends to forget (I do at least) that spawning a little helper process >> can be quite expensive, sometimes prohibitively so. Makes you wonder what >> kind of cross-platform alternatives there are! > > It shouldn't be. > > fork() does need to copy the page tables and mark the pages as shared. It also > means COW of certain pages. But the overhead shouldn't be that big. > > If anyone is seeing this, can you run your application with strace to get the > timings? > > strace -T -e clone > > Add -f if the forking is happening outside the main thread. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Tue Mar 7 22:35:46 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 7 Mar 2017 21:35:46 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: <1733911.qi4zXjP78C@tjmaciei-mobl1> <9A090E63-2A84-4C7E-B956-E1326388AC37@qt.io> Message-ID: <4BC45FE4-A56B-4937-A766-5CA858AB983E@qt.io> On 7 Mar 2017, at 22:24, Richard Moore > wrote: On 7 March 2017 at 21:21, Lars Knoll > wrote: > On 7 Mar 2017, at 21:54, Thiago Macieira > wrote: > > Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard Moore escreveu: >>> The Qt Company has now very recently made a decision to now go and invest >>> the man power required to turn qbs into a product we can fully support in >>> the future. This decision comes from the fact that we see that build >>> systems are a very integral part of the developer experience, and it's one >>> of the areas where we see that there still is a large potential for >>> improvement. qbs is promising to bring that improvement to us and our >>> users. >> ​Pretty depressing since the discussions at the developer summit seemed to >> conclude the exact opposite.​ I wish those developers were working on >> something more useful than a new wheel. The discussions there were afai remember inconclusive. But the people that do the actual work on the build system were mostly positive towards qbs. ​You didn't go to that session.​ You're right. My wording above was misleading, I wasn't present myself. This is what I remembered people telling me afterwards. Here are the session notes: https://wiki.qt.io/Qt_build_systems_at_QtCon_2016 Summary says: "We are thinking about switching build systems. We don't know what to do yet, but we can't decide it here." For me that's inconclusive. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich at kde.org Tue Mar 7 22:43:33 2017 From: rich at kde.org (Richard Moore) Date: Tue, 7 Mar 2017 21:43:33 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: <4BC45FE4-A56B-4937-A766-5CA858AB983E@qt.io> References: <1733911.qi4zXjP78C@tjmaciei-mobl1> <9A090E63-2A84-4C7E-B956-E1326388AC37@qt.io> <4BC45FE4-A56B-4937-A766-5CA858AB983E@qt.io> Message-ID: > > > You're right. My wording above was misleading, I wasn't present myself. > This is what I remembered people telling me afterwards. > > Here are the session notes: https://wiki.qt.io/Qt_ > build_systems_at_QtCon_2016 > > ​Yep, there's also a video. My recollection is that there was a small vocal group of people pushing qbs, but that they couldn't demonstrate any actual advantages it had. They offered a few up, but it turned out that people had already done that using other tools such as cmake. ​I think the only conclusion was that qmake is weak and that the maintainers want to stop maintaining it. Rich. > Summary says: "We are thinking about switching build systems. We don't > know what to do yet, but we can't decide it here." > > For me that's inconclusive. > > Cheers, > Lars > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.jabot at gmail.com Tue Mar 7 23:37:56 2017 From: corentin.jabot at gmail.com (Corentin) Date: Tue, 07 Mar 2017 22:37:56 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: <9A090E63-2A84-4C7E-B956-E1326388AC37@qt.io> References: <1733911.qi4zXjP78C@tjmaciei-mobl1> <9A090E63-2A84-4C7E-B956-E1326388AC37@qt.io> Message-ID: For what it's worth, as a Qt user, QBS was, last time I checked missing some features, like non-transitive compilatuons flags, platform support and documentation. That being said, in the past few years, I wrote some makefiles, some cmake projects. I've used WAF, qmake... QBS is the best C++ build system I've used. By far. The syntax is straightforward, logical, well thought out. For the most part, it is neither too verbose nor too little. I have managed to use it to generate intermediary files. (Maybe it still need better extensibility for that) I like that it works without stupid hardcoded paths, that it can be used to great effects for non-qt projects. Yes, it is yet another wheel, but it's a well engineered one. It fits nicely in the Qt ecosystem and if you are a little familiar with QML the learning curve is almost non existant. I've made the risky decision to use it on large-ish production software and I never regretted it. Porting existing librairies to qbs is straight forward. One could wish automatic conversion/import of cmake-base project but I have no idea if it's doable. I hardly see the need to import Qt-based libs in non-qt based projects so I don't see not using the headaches-inducing cmake as an issue. Le mar. 7 mars 2017 à 22:22, Lars Knoll a écrit : > > > On 7 Mar 2017, at 21:54, Thiago Macieira > wrote: > > > > Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard Moore > escreveu: > >>> The Qt Company has now very recently made a decision to now go and > invest > >>> the man power required to turn qbs into a product we can fully support > in > >>> the future. This decision comes from the fact that we see that build > >>> systems are a very integral part of the developer experience, and it's > one > >>> of the areas where we see that there still is a large potential for > >>> improvement. qbs is promising to bring that improvement to us and our > >>> users. > >> ​Pretty depressing since the discussions at the developer summit seemed > to > >> conclude the exact opposite.​ I wish those developers were working on > >> something more useful than a new wheel. > > The discussions there were afai remember inconclusive. But the people that > do the actual work on the build system were mostly positive towards qbs. > > > > Same here, though I have also to concede that breaking the status quo (to > > quote Jake's tweet) is sometimes a good idea. Teambuilder -- to name > another > > Trolltech project that had nothing to do with qt -- was a couple of > orders of > > magnitude better than the tools that existed at the time (distcc). > Icecream/ > > icecc came about only because TB wasn't open source, but every now and > then I > > miss TB2 features that icecc doesn't have. TB3 would have been even > better. > > > > Maybe qbs will be another such leapfrog. I can't fault TQtC for trying. > > That's what we believe. > > When we did the first version of Creator, everybody also thought we were > nuts, and that we should rather integrate with Eclipse ;-) > > Cheers, > Lars > > > > > But as I said, I agree with Richard and I can't help but feel that the > effort > > could have been turned into making cmake even better, especially > considering > > everyone[*] (including Microsoft!) is using it. > > > > [*] for some reason, the other project I work with (IoTivity) chose > Scons. > > Ugh... > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at familiesomers.nl Wed Mar 8 06:18:37 2017 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Wed, 8 Mar 2017 06:18:37 +0100 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: <1733911.qi4zXjP78C@tjmaciei-mobl1> <9A090E63-2A84-4C7E-B956-E1326388AC37@qt.io> <4BC45FE4-A56B-4937-A766-5CA858AB983E@qt.io> Message-ID: <8c3fcd2a-7708-528f-0af3-3d1b4e01488a@familiesomers.nl> Op 07/03/2017 om 22:43 schreef Richard Moore: > > > You're right. My wording above was misleading, I wasn't present > myself. This is what I remembered people telling me afterwards. > > Here are the session > notes: https://wiki.qt.io/Qt_build_systems_at_QtCon_2016 > > > > ​Yep, there's also a video. My recollection is that there was a small > vocal group of people pushing qbs, but that they couldn't demonstrate > any actual advantages it had. They offered a few up, but it turned out > that people had already done that using other tools such as cmake. ​I > think the only conclusion was that qmake is weak and that the > maintainers want to stop maintaining it. > The stopping maintainance of qmake can't happen any time soon I'd think. Not even from Qt6. There are too many Qt projects out there depending on it. André -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Mar 8 06:40:03 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 08 Mar 2017 06:40:03 +0100 Subject: [Development] QProcess fork() failure and overcommit In-Reply-To: <263AAAD9-8C89-440C-8EEF-83B7347E09D0@qt.io> References: <1805273.EBMQupCyU0@portia.local> <10562330.qO7P5klgjh@tjmaciei-mobl1> <263AAAD9-8C89-440C-8EEF-83B7347E09D0@qt.io> Message-ID: <2205200.TdXlbMvhWt@tjmaciei-mobl1> Em terça-feira, 7 de março de 2017, às 22:28:11 CET, Simon Hausmann escreveu: > I understand that this is in the context of Linux without overcommit. Which is exactly the situation in which forking should be fast. If it wasn't overcommitting, then the kernel would try and reserve the pages, possibly by freeing least-recently-used pages in other processes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From edward.welbourne at qt.io Wed Mar 8 11:07:31 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 8 Mar 2017 10:07:31 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: <8c3fcd2a-7708-528f-0af3-3d1b4e01488a@familiesomers.nl> References: <1733911.qi4zXjP78C@tjmaciei-mobl1> <9A090E63-2A84-4C7E-B956-E1326388AC37@qt.io> <4BC45FE4-A56B-4937-A766-5CA858AB983E@qt.io> , <8c3fcd2a-7708-528f-0af3-3d1b4e01488a@familiesomers.nl> Message-ID: André Somers (8 March 2017 06:18) > The stopping maintainance of qmake can't happen any time soon I'd > think. Not even from Qt6. There are too many Qt projects out there > depending on it. All the same, the sooner we can make the transition away from using it ourselves, the sooner we can retire qmake - albeit that'll surely be many releases later. If we can wean ourselves off it for Qt 6, there's some hope we might with good grace be able to abandon it at Qt 7. That's surely a long way off, but it'll be even longer if we don't get it out of our own way for Qt6. Whether we achieve that by switching to QBS or cmake (or to well-crafted naked make files) is a subject of utter indifference to me; but I, for one, long to see the day when I never have to shepherd another change to qmake through code review, Eddy. From Kai.Koehne at qt.io Wed Mar 8 11:37:43 2017 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 8 Mar 2017 10:37:43 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: <1733911.qi4zXjP78C@tjmaciei-mobl1> <9A090E63-2A84-4C7E-B956-E1326388AC37@qt.io> <4BC45FE4-A56B-4937-A766-5CA858AB983E@qt.io> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Richard Moore > Sent: Tuesday, March 07, 2017 10:44 PM > To: Lars Knoll > Cc: Thiago Macieira ; Qt development mailing > list > Subject: Re: [Development] syncqt.pl in C++ > > > You're right. My wording above was misleading, I wasn't present > myself. This is what I remembered people telling me afterwards. > > Here are the session notes: > https://wiki.qt.io/Qt_build_systems_at_QtCon_2016 > > > ​Yep, there's also a video. I was hosting this session. I don't think it was recorded. > My recollection is that there was a small vocal group > of people pushing qbs, but that they couldn't demonstrate any actual > advantages it had. They offered a few up, but it turned out that people had > already done that using other tools such as cmake. ​I think the only conclusion > was that qmake is weak and that the maintainers want to stop maintaining it. I take the blame for not preparing the session properly then. Anyhow, it was never intended as a decision forum in the first place. Take this as a statement of intent. The maintainer of the Qt build system (Ossi) and also the qbs developers (Joerg, Christian, Jake) would like to switch to qbs for building Qt in the mid-term, and we have the backing of the Chief Maintainer (Lars) for pushing this forward. The Qt Company sees the value in doing so, and is therefore resourcing this. We've been internally evaluating what's needed to get there, and will propose concrete steps on this mailing list at the appropriate time. We can have (and for sure will) have another round of discussions about whether cmake isn't the better alternative then. Anyhow, keep in mind that the Qt Project isn't a democracy, so don't expect a formal poll or so. Regards Kai From rich at kde.org Wed Mar 8 11:58:14 2017 From: rich at kde.org (Richard Moore) Date: Wed, 8 Mar 2017 10:58:14 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: <1733911.qi4zXjP78C@tjmaciei-mobl1> <9A090E63-2A84-4C7E-B956-E1326388AC37@qt.io> <4BC45FE4-A56B-4937-A766-5CA858AB983E@qt.io> Message-ID: On 8 March 2017 at 10:37, Kai Koehne wrote: > > -----Original Message----- > > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > > project.org] On Behalf Of Richard Moore > > Sent: Tuesday, March 07, 2017 10:44 PM > > To: Lars Knoll > > Cc: Thiago Macieira ; Qt development mailing > > list > > Subject: Re: [Development] syncqt.pl in C++ > > > > > > You're right. My wording above was misleading, I wasn't present > > myself. This is what I remembered people telling me afterwards. > > > > Here are the session notes: > > https://wiki.qt.io/Qt_build_systems_at_QtCon_2016 > > > > > > ​Yep, there's also a video. > > I was hosting this session. I don't think it was recorded. > > http://files.kde.org/akademy/2016/A05_Day2_Qt_Build_Systems.mp4 ​Rich.​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Wed Mar 8 12:33:39 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Wed, 8 Mar 2017 11:33:39 +0000 Subject: [Development] Problem loading plugins with gcc 4.9.2 In-Reply-To: <1898969.QfyxV4QgUg@tjmaciei-mobl4> References: <1537832.K0UFH4PlVN@desktop> <77420564-4CFA-4C4C-9DCA-4F7B056A5E9F@digia.com> , <1898969.QfyxV4QgUg@tjmaciei-mobl4> Message-ID: This is an ancient thread but just to keep this in mind (it certainly cost me a day re-figuring this out). If you do Qt development for Android you are going to be hit by this. The four most recent Android NDKs (11c, 12b, 13b & 14) are affected by this bug when using Linux (not all Linux distros though but certainly Ubuntu 16.04) as host platform. The only decent choice is 10e at this point in time. I am tempted to just submit a patch that renames the damn loader variables. Any opinions? -- Alex ________________________________________ From: development-bounces+alexander.blasche=theqtcompany.com at qt-project.org on behalf of Thiago Macieira Sent: Wednesday, 4 March 2015 4:48:11 PM To: development at qt-project.org Subject: Re: [Development] Problem loading plugins with gcc 4.9.2 On Wednesday 04 March 2015 11:53:04 Albert Astals Cid wrote: > Yes, same issue. > > Reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65309 > > Would be great if someone could verify i didn't say lots of silly things Given they've just confirmed, produced a fix and committed it, I'm guessing you didn't say anything silly :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From iamsergio at gmail.com Wed Mar 8 12:55:58 2017 From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Wed, 8 Mar 2017 11:55:58 +0000 Subject: [Development] Problem loading plugins with gcc 4.9.2 In-Reply-To: References: <1537832.K0UFH4PlVN@desktop> <77420564-4CFA-4C4C-9DCA-4F7B056A5E9F@digia.com> <1898969.QfyxV4QgUg@tjmaciei-mobl4> Message-ID: On Wed, Mar 8, 2017 at 11:33 AM, Alex Blasche wrote: > This is an ancient thread but just to keep this in mind (it certainly cost me a day re-figuring this out). > > If you do Qt development for Android you are going to be hit by this. The four most recent Android NDKs (11c, 12b, 13b & 14) are affected by this bug when using Linux (not all Linux distros though but certainly Ubuntu 16.04) as host platform. The only decent choice is 10e at this point in time. > > I am tempted to just submit a patch that renames the damn loader variables. Any opinions? Hi, Options: - Use the latest NDKs, but with clang instead of gcc - Use the latest NDKs with gcc but don't compile in debug mode (release doesn't crash) - Use 10e I prefer option 1, sooner or later that gcc will rot, since google stopped supporting it. Regards, Sérgio Martins From chgans at gna.org Wed Mar 8 13:14:10 2017 From: chgans at gna.org (Ch'Gans) Date: Thu, 9 Mar 2017 01:14:10 +1300 Subject: [Development] Problem loading plugins with gcc 4.9.2 In-Reply-To: References: <1537832.K0UFH4PlVN@desktop> <77420564-4CFA-4C4C-9DCA-4F7B056A5E9F@digia.com> <1898969.QfyxV4QgUg@tjmaciei-mobl4> Message-ID: On 9 March 2017 at 00:33, Alex Blasche wrote: > This is an ancient thread but just to keep this in mind (it certainly cost me a day re-figuring this out). > > If you do Qt development for Android you are going to be hit by this. The four most recent Android NDKs (11c, 12b, 13b & 14) are affected by this bug when using Linux (not all Linux distros though but certainly Ubuntu 16.04) as host platform. The only decent choice is 10e at this point in time. > > I am tempted to just submit a patch that renames the damn loader variables. Any opinions? Please stop top-posting: http://letmegooglethat.com/?q=top+posting&l=1 and stop sending HTML emails: http://www.catb.org/~esr/faqs/smart-questions.html#formats Grumpy Chris. > > -- > Alex > ________________________________________ > From: development-bounces+alexander.blasche=theqtcompany.com at qt-project.org on behalf of Thiago Macieira > Sent: Wednesday, 4 March 2015 4:48:11 PM > To: development at qt-project.org > Subject: Re: [Development] Problem loading plugins with gcc 4.9.2 > > On Wednesday 04 March 2015 11:53:04 Albert Astals Cid wrote: >> Yes, same issue. >> >> Reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65309 >> >> Would be great if someone could verify i didn't say lots of silly things > > Given they've just confirmed, produced a fix and committed it, I'm guessing you > didn't say anything silly :-) > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed Mar 8 13:30:31 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 08 Mar 2017 13:30:31 +0100 Subject: [Development] Problem loading plugins with gcc 4.9.2 In-Reply-To: References: <1537832.K0UFH4PlVN@desktop> Message-ID: <3004577.r9NEpRTELU@tjmaciei-mobl1> Em quarta-feira, 8 de março de 2017, às 12:55:58 CET, Sérgio Martins escreveu: > On Wed, Mar 8, 2017 at 11:33 AM, Alex Blasche wrote: > > This is an ancient thread but just to keep this in mind (it certainly cost > > me a day re-figuring this out). > > > > If you do Qt development for Android you are going to be hit by this. The > > four most recent Android NDKs (11c, 12b, 13b & 14) are affected by this > > bug when using Linux (not all Linux distros though but certainly Ubuntu > > 16.04) as host platform. The only decent choice is 10e at this point in > > time. > > > > I am tempted to just submit a patch that renames the damn loader > > variables. Any opinions? > Hi, > > Options: > > - Use the latest NDKs, but with clang instead of gcc > - Use the latest NDKs with gcc but don't compile in debug mode > (release doesn't crash) > - Use 10e > > I prefer option 1, sooner or later that gcc will rot, since google > stopped supporting it. I'm with Sergio, since Clang appears to be the future direction anyway. Speaking to Bogdan on IRC a few days ago, it turns out that we haven't been using Clang because it has much poorer optimisations than GCC (that's not news), and produces much bigger code than GCC when compiled with -Os. Size itself is not a big deal, but apparently it causes execution to be slower on ARM 32-bit -- probably due to cache limitations. He's now testing -Oz (aggressive optimise for size) and will let us know if it helps. I can tell you that -Oz produces executables of comparable size with GCC -Os, but still bigger. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Mar 8 13:32:11 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 08 Mar 2017 13:32:11 +0100 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: Message-ID: <8462701.j6QcUqPeVg@tjmaciei-mobl1> Em quarta-feira, 8 de março de 2017, às 11:37:43 CET, Kai Koehne escreveu: > I take the blame for not preparing the session properly then. Anyhow, it was > never intended as a decision forum in the first place. It couldn't have been. Only this mailing list is allowed to make decisions for the Qt Project. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From christian.kandeler at qt.io Wed Mar 8 13:51:49 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Wed, 8 Mar 2017 13:51:49 +0100 Subject: [Development] QProcess fork() failure and overcommit In-Reply-To: <10562330.qO7P5klgjh@tjmaciei-mobl1> References: <1805273.EBMQupCyU0@portia.local> <2206946.pQ9Pcv2lim@kerberos> <13254176.C6KrK6M3W4@portia.local> <10562330.qO7P5klgjh@tjmaciei-mobl1> Message-ID: On 03/07/2017 10:05 PM, Thiago Macieira wrote: > Em terça-feira, 7 de março de 2017, às 17:53:41 CET, René J.V. Bertin > escreveu: >> One tends to forget (I do at least) that spawning a little helper process >> can be quite expensive, sometimes prohibitively so. Makes you wonder what >> kind of cross-platform alternatives there are! > > It shouldn't be. > > fork() does need to copy the page tables and mark the pages as shared. It also > means COW of certain pages. But the overhead shouldn't be that big. > > If anyone is seeing this, can you run your application with strace to get the > timings? > > strace -T -e clone I use the default settings for overcommit (0/heuristic). My application starts QProcesses in a loop. If the application has not allocated additional memory, strace -T for clone() gives: <0.000079> <0.000091> <0.000205> <0.000090> <0.000119> <0.000112> <0.000231> <0.000096> <0.000114> <0.000112> Here's the same application using 1GB of additional memory: <0.012753> <0.016715> <0.015152> <0.014449> <0.012960> <0.016914> <0.013560> <0.013337> <0.012911> <0.013019> So, factors around 100? (Also, I get lots of ERESTARTNOINTR in the latter case). Christian From thiago.macieira at intel.com Wed Mar 8 14:32:58 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 08 Mar 2017 14:32:58 +0100 Subject: [Development] QProcess fork() failure and overcommit In-Reply-To: References: <1805273.EBMQupCyU0@portia.local> <10562330.qO7P5klgjh@tjmaciei-mobl1> Message-ID: <3218548.6OdA4LeEoI@tjmaciei-mobl1> Em quarta-feira, 8 de março de 2017, às 13:51:49 CET, Christian Kandeler escreveu: > I use the default settings for overcommit (0/heuristic). My application > starts QProcesses in a loop. If the application has not allocated > additional memory, strace -T for clone() gives: > > <0.000079> > <0.000091> > <0.000205> > <0.000090> > <0.000119> > <0.000112> > <0.000231> > <0.000096> > <0.000114> > <0.000112> > > Here's the same application using 1GB of additional memory: > > <0.012753> > <0.016715> > <0.015152> > <0.014449> > <0.012960> > <0.016914> > <0.013560> > <0.013337> > <0.012911> > <0.013019> > > So, factors around 100? Not unexpected, if you use 100x more memory. clone() has a fixed cost for creating the necessary book-keeping and it may have some non-O(1) dependent on the number of running processes running, but it's definitely O(n) on the memory -- the Linux kernel does not apply the book-keeping on the 2MB page table directory level, only on the actual 4 kB page table entries. That said, look at the numbers: it increased from ~100 µs to 16.9 ms in the worst case. You can't perceive that difference. > (Also, I get lots of ERESTARTNOINTR in the latter case). Ignore that, it's not visible. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ulf.hermann at qt.io Wed Mar 8 14:44:51 2017 From: ulf.hermann at qt.io (Ulf Hermann) Date: Wed, 8 Mar 2017 14:44:51 +0100 Subject: [Development] QProcess fork() failure and overcommit In-Reply-To: <3218548.6OdA4LeEoI@tjmaciei-mobl1> References: <1805273.EBMQupCyU0@portia.local> <10562330.qO7P5klgjh@tjmaciei-mobl1> <3218548.6OdA4LeEoI@tjmaciei-mobl1> Message-ID: <6ad44b5f-387c-427c-f0be-50d2b24c1612@qt.io> > That said, look at the numbers: it increased from ~100 µs to 16.9 ms in the > worst case. You can't perceive that difference. This limits the number of processes you can spawn per second to about 60 (and it goes lower if you eat more RAM). I certainly can notice this when using the version of qbs compiled into QtCreator to compile a project. In order to keep an 8-core CPU loaded and send extra jobs to icecream you need a higher rate. There is a workaround for that by now, which just uses a separate process to spawn the children, but it used to be a problem. Ulf From thiago.macieira at intel.com Wed Mar 8 15:29:28 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 08 Mar 2017 15:29:28 +0100 Subject: [Development] QProcess fork() failure and overcommit In-Reply-To: <6ad44b5f-387c-427c-f0be-50d2b24c1612@qt.io> References: <1805273.EBMQupCyU0@portia.local> <3218548.6OdA4LeEoI@tjmaciei-mobl1> <6ad44b5f-387c-427c-f0be-50d2b24c1612@qt.io> Message-ID: <3047564.xAGk4P0jx8@tjmaciei-mobl1> Em quarta-feira, 8 de março de 2017, às 14:44:51 CET, Ulf Hermann escreveu: > > That said, look at the numbers: it increased from ~100 µs to 16.9 ms in > > the > > worst case. You can't perceive that difference. > > This limits the number of processes you can spawn per second to about 60 > (and it goes lower if you eat more RAM). Why would Qt Creator want to spawn more than 60 processes per second? > I certainly can notice this > when using the version of qbs compiled into QtCreator to compile a > project. In order to keep an 8-core CPU loaded and send extra jobs to > icecream you need a higher rate. > > There is a workaround for that by now, which just uses a separate > process to spawn the children, but it used to be a problem. Oh, that explains.Separate process is the correct solution. I 've just tried gmake in a very simple project and it called vfork() 26 times in a total runtime of 0.5 seconds -- that is, 52 times per second. That's a total count in the same order than the overhead inside Qt Creator. Note: gmake uses vfork(), whose stated goal is to avoid doing a page table duplication; QProcess and forkfd cannot do that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oswald.buddenhagen at qt.io Wed Mar 8 18:55:32 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 8 Mar 2017 18:55:32 +0100 Subject: [Development] syncqt.pl in C++ In-Reply-To: <1840274.Il0Y8UKPlW@tjmaciei-mobl1> References: <5357767.Bo3xEg3dNL@tjmaciei-mobl1> <922C5F2D-EA4C-46EA-957A-CD281D0AFF3A@qt.io> <1840274.Il0Y8UKPlW@tjmaciei-mobl1> Message-ID: <20170308175532.GD19298@troll08> On Tue, Mar 07, 2017 at 11:46:58AM +0100, Thiago Macieira wrote: > Em terça-feira, 7 de março de 2017, às 08:16:14 CET, Simon Hausmann escreveu: > > I for one would welcome a C++ rewrite of syncqt inside qmake to get rid of > > the perl dependency. However I do not have the authority to approve such a > > contribution. It is something we have talked about many times on the > > hallway. > i think i'd approve it at this point. however, i don't want a 1:1 port of the perl code, because sync.profile is kinda nuts, with multiple mostly redundant ways to specify things. also, perl isn't exactly the optimal input language for non-perl interpreters. a nice per-module json file would do. > You have a chicken-and-the-egg problem here, as qmake depends on the headers > being generated by syncqt before it can be compiled. > it's not that bad. the bootstrapped build uses syncqt -minimal, which just collects the lowercase headers. this could be done adequately with sh and even cmd. > I read the OP's email as a request to write it in non-Qt C++ so we could drop > the Perl dependency. I don't think we want that, it's not worth the effort. > i also don't think it's *worth* it, especially with The New Build System (TM) looming not too far off. however, i'd be willing to review a relevant contribution - provided it's done competently enough that it doesn't have to go through dozens of tiresome rounds of review. > > Until we arrive in the promised land of a new build system, it would > > allow us to simplify our source packaging even further the moment we > > have it (syncqt C++). > > syncqt in qmake, yes, possibly. > > Rewrite it in non-Qt C++, please no. > i wouldn't be fundamentally opposed to stl, as the tool is small enough and self-contained. however, it seems stupid not to do it as part of qmake given that it already has the rudimentary c++ parser that's needed (currently used for dependency scanning). and the headers.pri file created by syncqt is meant for qmake consumption anyway ... another option is exposing c++ parser primitives from qmake and implementing the higher-level functionality in the qmake language. the value of this exercise would be a prototype for a possible implementation in qbs - a purely js-based implementation is somewhat slow-ish. From nospam at vuorela.dk Wed Mar 8 20:53:17 2017 From: nospam at vuorela.dk (Sune Vuorela) Date: Wed, 8 Mar 2017 19:53:17 +0000 (UTC) Subject: [Development] syncqt.pl in C++ References: Message-ID: On 2017-03-07, Lars Knoll wrote: > This also makes qbs a natural choice to also use for Qt itself, and I belie= > ve all the people that have worked and maintained Qt's build system over th= > e last few years are supporting this. Of course this requires that we can s= > how that qbs can be used to build Qt. I expect this also includes "Can be bootstrapped" and "Does not require a qbs executable obtained from elsewhere with all dependencies". And maybe even "Can be built on platforms where v4 isn't yet ported." /Sune From Jake.Petroules at qt.io Wed Mar 8 21:09:49 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 8 Mar 2017 20:09:49 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: , Message-ID: I'm working on the qbs bootstrapping. The requirements will be: a C++11 compiler. End of requirements. Seriously. Not even bash, if you don't mind typing a couple commands manually. Right now we depend on JSC via QtScript (not V4) but that will change at some point. We're not entirely sure of the solution yet; newer JSC vs V8 vs V4 or another solution. JSC supports ES2017 nowadays so I somewhat favor that. Qt could then include a tiny bootstrap script which downloads and bootstraps qbs, then builds Qt (but the normal use case would be that you already have qbs installed). -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ________________________________ From: Development on behalf of Sune Vuorela Sent: Wednesday, March 8, 2017 11:53:17 AM To: development at qt-project.org Subject: Re: [Development] syncqt.pl in C++ On 2017-03-07, Lars Knoll wrote: > This also makes qbs a natural choice to also use for Qt itself, and I belie= > ve all the people that have worked and maintained Qt's build system over th= > e last few years are supporting this. Of course this requires that we can s= > how that qbs can be used to build Qt. I expect this also includes "Can be bootstrapped" and "Does not require a qbs executable obtained from elsewhere with all dependencies". And maybe even "Can be built on platforms where v4 isn't yet ported." /Sune _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From nospam at vuorela.dk Wed Mar 8 21:15:46 2017 From: nospam at vuorela.dk (Sune Vuorela) Date: Wed, 8 Mar 2017 20:15:46 +0000 (UTC) Subject: [Development] syncqt.pl in C++ References: Message-ID: On 2017-03-08, Jake Petroules wrote: > I'm working on the qbs bootstrapping. The requirements will be: a C++11 com= > piler. End of requirements. Seriously. Not even bash, if you don't mind typ= > ing a couple commands manually. I don't mind a bat script, a bash script or whatever is needed, but that sounds great. > > Qt could then include a tiny bootstrap script which downloads and bootstrap= > s qbs, then builds Qt (but the normal use case would be that you already ha= > ve qbs installed). I really think that building Qt in the normal usecase would not involve using Qt libraries. And a normal build setup should not touch the network at all. /Sune From Jake.Petroules at qt.io Wed Mar 8 21:23:58 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 8 Mar 2017 20:23:58 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: Message-ID: <04773099-0BC0-423D-B501-D3C72B3E42B2@qt.io> > On Mar 8, 2017, at 12:15 PM, Sune Vuorela wrote: > > On 2017-03-08, Jake Petroules wrote: >> I'm working on the qbs bootstrapping. The requirements will be: a C++11 com= >> piler. End of requirements. Seriously. Not even bash, if you don't mind typ= >> ing a couple commands manually. > > I don't mind a bat script, a bash script or whatever is needed, but > that sounds great. >> >> Qt could then include a tiny bootstrap script which downloads and bootstrap= >> s qbs, then builds Qt (but the normal use case would be that you already ha= >> ve qbs installed). > > I really think that building Qt in the normal usecase would not involve > using Qt libraries. And a normal build setup should not touch the > network at all. In general I agree. If Qt was built with CMake, you wouldn't expect the Qt build scripts to obtain and bootstrap CMake itself. So I think that if it does so for qbs, you're already "getting more than you deserve". ;) The general idea is kind of following that of the Gradle wrapper, where any project that uses the Gradle build system also can include a standard wrapper script which obtains and bootstraps the build system itself before building your project, allowing ANY project based on that build system to be "zero dependencies". git clone & go, the system figures out the rest as much as it can. If qbs has similar capabilities like that, including online dependency fetching, I think a lot of people would appreciate it. Personally, I also prefer a build process never touch the network, but the average developer isn't that picky and just wants to Get Things Done. > /Sune > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From vseryakov at gmail.com Thu Mar 9 06:33:11 2017 From: vseryakov at gmail.com (Vlad Seryakov) Date: Thu, 9 Mar 2017 00:33:11 -0500 Subject: [Development] Qt mobile input context scrolling Message-ID: Hello, I am trying to disable Qt auto-scrolling on mobile devices(iOS, Android) when focusing on an input field in QtQuick. For iOS it was pretty simple and just for a proof of concept making QIOSInputContext::scrollableRootView to always to return 0 disabled the auto-scrolling so we can in our app deal with keyboard showing or hiding. We have our own complex UI and auto-scrolling makes it a bad user experience. Dealing with it turned out to be more work and never ending race condition. So, it works very good now on iOS, my next step will be android and this is not that straightforward. Not familiar with Android internals, and after reading Android platform plugin and base java/jar sources i am still puzzled when the scrolling happens. Does anybody can point me where to look? This will save time but i am going to dig into it anyway, so this is not a request. The actual question is, if disabling will show it is possible, what would be the solution to make it available to developers? For complex apps, the auto-scroll does not make sense. I looked into QPlatformIntegration classes, the only generic method is to set QPlatformWindow flags. At the same time with this little switch i do not want to break binary compatibility or change a lot of base classes. Having it available in the C++ at least makes it flexible to use the auto-scroll or not. Thanks From thiago.macieira at intel.com Thu Mar 9 07:55:26 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 09 Mar 2017 07:55:26 +0100 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: Message-ID: <1529832.zzSgnqPmnO@tjmaciei-mobl1> Em quarta-feira, 8 de março de 2017, às 21:09:49 CET, Jake Petroules escreveu: > Right now we depend on JSC via QtScript (not V4) but that will change at > some point. We're not entirely sure of the solution yet; newer JSC vs V8 vs > V4 or another solution. Have you tried the JerryScript interpreter? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From olivier at woboq.com Thu Mar 9 09:08:38 2017 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 09 Mar 2017 09:08:38 +0100 Subject: [Development] Qt mobile input context scrolling In-Reply-To: References: Message-ID: <1809722.lAUOQvJDGI@maurice> On Donnerstag, 9. März 2017 06:33:11 CET Vlad Seryakov wrote: > Hello, > I am trying to disable Qt auto-scrolling on mobile devices(iOS, Android) > when focusing on an input field in QtQuick. > > For iOS it was pretty simple and just for a proof of concept making > QIOSInputContext::scrollableRootView to always to return 0 disabled the > auto-scrolling so we can in our app deal with keyboard showing or hiding. > We have our own complex UI and auto-scrolling makes it a bad user > experience. Dealing with it turned out to be more work and never ending > race condition. > > So, it works very good now on iOS, my next step will be android and this is > not that straightforward. Not familiar with Android internals, and after > reading Android platform plugin and base java/jar sources i am still > puzzled when the scrolling happens. > > Does anybody can point me where to look? This will save time but i am going > to dig into it anyway, so this is not a request. In the manifest file, you can use the setting android:windowSoftInputMode="adjustResize" https://developer.android.com/guide/topics/manifest/activity-element.html Personally, I think this is a much better setting that the panning, I wonder if it should be made the default. Most non-qt android application i've seen used that. (However, there was a bug with Qt 5.6 that caused a flickering, I don't know if it has been fixed since) > The actual question is, if disabling will show it is possible, what would be > the solution to make it available to developers? For complex apps, the > auto-scroll does not make sense. I looked into QPlatformIntegration > classes, the only generic method is to set QPlatformWindow flags. At the > same time with this little switch i do not want to break binary > compatibility or change a lot of base classes. Having it available in the > C++ at least makes it flexible to use the auto-scroll or not. I believe the resizing the window is the way to go. Then, there is still need to do some integration to make sure that if there is a Flickable on this view, the input control stays visible (i.e: the Flickable scrolls to the right position). I have done that in QML in an application's own controls. But I believe it should be the default in Qt. (You may wonder what's the difference between having the window being scrolled, or the Flickable being scrolled. The latter allow the user to continue to interact with the application normally, while the former hides the top part (which might include a title bar for example) and makes it harder for the user to navigate to other fields) -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From konrad at silmor.de Thu Mar 9 11:22:28 2017 From: konrad at silmor.de (Konrad Rosenbaum) Date: Thu, 9 Mar 2017 11:22:28 +0100 Subject: [Development] syncqt.pl in C++ In-Reply-To: <04773099-0BC0-423D-B501-D3C72B3E42B2@qt.io> References: <04773099-0BC0-423D-B501-D3C72B3E42B2@qt.io> Message-ID: <20ddbd3a964fb631cf8b39d8c59c0eac.squirrel@squirrel.six.silmor.de> Hi, On Wed, March 8, 2017 21:23, Jake Petroules wrote: > Personally, I also prefer a build process never touch the network, but the > average developer isn't that picky and just wants to Get Things Done. The average test engineer is that picky and even worse! A test engineer expects to save a minimal VM of the build system, boot it up a year later in a completely isolated environment (i.e. no network or access to external repositories) and then it should build the exact same binaries bit for bit (minus the file create time). Also: I've worked in environments in which a network connection for build scripts would have been quite difficult to accomplish if not impossible (e.g. isolated servers with no access to the web proxy or proxies with rather strange setups). Every little dependency had to be downloaded manually (sometimes from a completely different network) and transferred into the build environment over several stages - that's especially funny if you're building from source because the pre-built binaries don't run because they require a newer system. No, those environments are exceedingly common in industry. If you want to keep the Qt build process as flexible as possible: 1) minimal dependencies (i.e. compiler, maybe one or two simple tools) 2) no network access 3) can be built completely from sources, no binaries in the archive 4) no self-dependency (i.e. does not require binaries of itself to build) otherwise: expect complaints from people living what is jokingly called "real life". ;-) Do NOT expect modern connected systems at the user's side! Konrad From samuel.nevala at intopalo.com Thu Mar 9 11:47:23 2017 From: samuel.nevala at intopalo.com (Samuel Nevala) Date: Thu, 9 Mar 2017 12:47:23 +0200 Subject: [Development] Qt mobile input context scrolling In-Reply-To: <1809722.lAUOQvJDGI@maurice> References: <1809722.lAUOQvJDGI@maurice> Message-ID: Would be great to see resize as default option but there is visual glitches when using resize https://bugreports.qt.io/browse/QTBUG-41170. Samuel Nevala On 9 March 2017 at 10:08, Olivier Goffart wrote: > On Donnerstag, 9. März 2017 06:33:11 CET Vlad Seryakov wrote: > > Hello, > > I am trying to disable Qt auto-scrolling on mobile devices(iOS, Android) > > when focusing on an input field in QtQuick. > > > > For iOS it was pretty simple and just for a proof of concept making > > QIOSInputContext::scrollableRootView to always to return 0 disabled the > > auto-scrolling so we can in our app deal with keyboard showing or hiding. > > We have our own complex UI and auto-scrolling makes it a bad user > > experience. Dealing with it turned out to be more work and never ending > > race condition. > > > > So, it works very good now on iOS, my next step will be android and this > is > > not that straightforward. Not familiar with Android internals, and after > > reading Android platform plugin and base java/jar sources i am still > > puzzled when the scrolling happens. > > > > Does anybody can point me where to look? This will save time but i am > going > > to dig into it anyway, so this is not a request. > > In the manifest file, you can use the setting > android:windowSoftInputMode="adjustResize" > > https://developer.android.com/guide/topics/manifest/activity-element.html > > Personally, I think this is a much better setting that the panning, I > wonder > if it should be made the default. Most non-qt android application i've seen > used that. > (However, there was a bug with Qt 5.6 that caused a flickering, I don't > know > if it has been fixed since) > > > The actual question is, if disabling will show it is possible, what > would be > > the solution to make it available to developers? For complex apps, the > > auto-scroll does not make sense. I looked into QPlatformIntegration > > classes, the only generic method is to set QPlatformWindow flags. At the > > same time with this little switch i do not want to break binary > > compatibility or change a lot of base classes. Having it available in the > > C++ at least makes it flexible to use the auto-scroll or not. > > I believe the resizing the window is the way to go. Then, there is still > need > to do some integration to make sure that if there is a Flickable on this > view, > the input control stays visible (i.e: the Flickable scrolls to the right > position). I have done that in QML in an application's own controls. But I > believe it should be the default in Qt. > > (You may wonder what's the difference between having the window being > scrolled, or the Flickable being scrolled. The latter allow the user to > continue to interact with the application normally, while the former hides > the > top part (which might include a title bar for example) and makes it harder > for > the user to navigate to other fields) > > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - > https://code.woboq.org > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathias.hasselmann at kdab.com Thu Mar 9 11:47:32 2017 From: mathias.hasselmann at kdab.com (Mathias Hasselmann) Date: Thu, 9 Mar 2017 11:47:32 +0100 Subject: [Development] syncqt.pl in C++ In-Reply-To: <04773099-0BC0-423D-B501-D3C72B3E42B2@qt.io> References: <04773099-0BC0-423D-B501-D3C72B3E42B2@qt.io> Message-ID: <91ee35fb-5b4a-f679-a2b2-66a15618796c@kdab.com> Am 08.03.2017 um 21:23 schrieb Jake Petroules: > The general idea is kind of following that of the Gradle wrapper, > where any project that uses the Gradle build system also can include > a standard wrapper script which obtains and bootstraps the build > system itself before building your project, allowing ANY project > based on that build system to be "zero dependencies". git clone & go, > the system figures out the rest as much as it can. If qbs has similar > capabilities like that, including online dependency fetching, I think > a lot of people would appreciate it. Did you do any user research backing this claim, or is this a plain gut feeling? I know for a fact that Gradle and it's downloading features actually cause serious problems for some of our customers who sit behind restrictive firewalls and have to use complex proxy setups to reach the Internet. They basically have to circumvent countless company policies just to bootstrap Gradle. Besides I somehow doubt that it is even remotely reasonable to mimic a build system that weights 225 MiB in size. Tools should know their task and focus on that. No need for a kitchen sink. Ciao, Mathias -- Mathias Hasselmann | mathias.hasselmann at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325485 / +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4016 bytes Desc: S/MIME Cryptographic Signature URL: From Karsten.Heimrich at qt.io Thu Mar 9 12:28:58 2017 From: Karsten.Heimrich at qt.io (Karsten Heimrich) Date: Thu, 9 Mar 2017 11:28:58 +0000 Subject: [Development] Qt Visual Studio Tools (Beta) for Visual Studio 2017 Message-ID: Hi, I am happy to inform you that we uploaded an initial version of our Qt Visual Studio Tools with support for VS 2017 to http://download.qt.io/development_releases/vsaddin br, Karsten Heimrich -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhihn at gmx.com Thu Mar 9 17:52:26 2017 From: jhihn at gmx.com (Jason H) Date: Thu, 9 Mar 2017 17:52:26 +0100 Subject: [Development] Qt mobile input context scrolling In-Reply-To: References: Message-ID: > Hello, > I am trying to disable Qt auto-scrolling on mobile devices(iOS, Android) when focusing on an input field in QtQuick. > > For iOS it was pretty simple and just for a proof of concept making QIOSInputContext::scrollableRootView to always to return 0 disabled the auto-scrolling so we can in our app deal with keyboard showing or hiding. We have our own complex UI and auto-scrolling makes it a bad user experience. > Dealing with it turned out to be more work and never ending race condition. > > So, it works very good now on iOS, my next step will be android and this is not that straightforward. Not familiar with Android internals, and after reading Android platform plugin and base java/jar sources i am still puzzled when the scrolling happens. > > Does anybody can point me where to look? This will save time but i am going to dig into it anyway, so this is not a request. > > The actual question is, if disabling will show it is possible, what would be the solution to make it available to developers? For complex apps, the auto-scroll does not make sense. > I looked into QPlatformIntegration classes, the only generic method is to set QPlatformWindow flags. At the same time with this little switch i do not want to break binary compatibility or change a lot of base classes. Having it available in the C++ at least makes it flexible to use the auto-scroll or not. I do have some experience with this, yeah, I find it frustrating at times. What I did was to represent the keyboard rect in my layout. But as you can see with the code below, I commented it out. I remember having experiences some Android/iOS differences. (As evidenced by the logic). It seems that this code was to handle the issue of the keyboard coming up over the listview. I also have have a comment in my android manifest: which seems to indicate that I removed that from the defaults, or I at least experimented with it. Anyhow, better control of the keyboard/window behavior would be greatly appreciated. Item { id: keyboardSpacer height: 0 anchors{ left: parent.left right: parent.right bottom: parent.bottom } } Connections { target: Qt.inputMethod onKeyboardRectangleChanged: { console.log("Qt.inputMethod.visible:", Qt.inputMethod.visible, Qt.inputMethod.keyboardRectangle.height //keyboardSpacer.height = (Qt.platform.os === "android") ? Qt.inputMethod.keyboardRectangle.height / Screen.devicePixelRatio: 0; listView.positionViewAtEnd() } } From marc.mutz at kdab.com Thu Mar 9 18:07:43 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 9 Mar 2017 18:07:43 +0100 Subject: [Development] Help needed: Qt 3D Android build issue In-Reply-To: <2089571.91Rdrn5KjH@cartman> References: <1581822.graGXO5Myn@titan> <201605260832.23579.marc.mutz@kdab.com> <2089571.91Rdrn5KjH@cartman> Message-ID: <201703091807.43777.marc.mutz@kdab.com> On Thursday 26 May 2016 14:00:44 Sean Harmer wrote: > If anybody else if using 4.8 then they can try this patch. This cropped up again: http://bugreports.qt.io/browse/QTBUG-59399 → https://codereview.qt-project.org/187980 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From perezmeyer at gmail.com Thu Mar 9 18:14:09 2017 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Thu, 09 Mar 2017 14:14:09 -0300 Subject: [Development] syncqt.pl in C++ In-Reply-To: <20ddbd3a964fb631cf8b39d8c59c0eac.squirrel@squirrel.six.silmor.de> References: <04773099-0BC0-423D-B501-D3C72B3E42B2@qt.io> <20ddbd3a964fb631cf8b39d8c59c0eac.squirrel@squirrel.six.silmor.de> Message-ID: <1959816.zn8vqOkt9k@tonks> On jueves, 9 de marzo de 2017 11:22:28 ART Konrad Rosenbaum wrote: > Hi, > > On Wed, March 8, 2017 21:23, Jake Petroules wrote: > > Personally, I also prefer a build process never touch the network, but the > > average developer isn't that picky and just wants to Get Things Done. > > The average test engineer is that picky and even worse! A test engineer > expects to save a minimal VM of the build system, boot it up a year later > in a completely isolated environment (i.e. no network or access to > external repositories) and then it should build the exact same binaries > bit for bit (minus the file create time). > > Also: I've worked in environments in which a network connection for build > scripts would have been quite difficult to accomplish if not impossible > (e.g. isolated servers with no access to the web proxy or proxies with > rather strange setups). Uff, this would be me doing stuff at $job and another part of me maintaining Qt for Debian. No network access, in both cases, is a must. > Every little dependency had to be downloaded > manually (sometimes from a completely different network) and transferred > into the build environment over several stages - that's especially funny > if you're building from source because the pre-built binaries don't run > because they require a newer system. No, those environments are > exceedingly common in industry. > > If you want to keep the Qt build process as flexible as possible: > > 1) minimal dependencies (i.e. compiler, maybe one or two simple tools) > 2) no network access > 3) can be built completely from sources, no binaries in the archive > 4) no self-dependency (i.e. does not require binaries of itself to build) Exactly. > otherwise: expect complaints from people living what is jokingly called > "real life". ;-) Count me on that list. -- Simulations are not data. In God we trust, all the others must supply data. Walter Opyd, "Show Me The Data" IEEE Spectrum's reader's comments, http://www.spectrum.ieee.org/nov04/4004 Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From Jake.Petroules at qt.io Thu Mar 9 19:01:44 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Thu, 9 Mar 2017 18:01:44 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: <91ee35fb-5b4a-f679-a2b2-66a15618796c@kdab.com> References: <04773099-0BC0-423D-B501-D3C72B3E42B2@qt.io> <91ee35fb-5b4a-f679-a2b2-66a15618796c@kdab.com> Message-ID: <09357C28-4B0F-4914-B593-146979AE540F@qt.io> > On Mar 9, 2017, at 2:47 AM, Mathias Hasselmann wrote: > > > > Am 08.03.2017 um 21:23 schrieb Jake Petroules: >> The general idea is kind of following that of the Gradle wrapper, >> where any project that uses the Gradle build system also can include >> a standard wrapper script which obtains and bootstraps the build >> system itself before building your project, allowing ANY project >> based on that build system to be "zero dependencies". git clone & go, >> the system figures out the rest as much as it can. If qbs has similar >> capabilities like that, including online dependency fetching, I think >> a lot of people would appreciate it. > > Did you do any user research backing this claim, or is this a plain gut feeling? CocoaPods is quite well loved by the Apple development community, which operates on the same principle as Gradle in that regard (personally I'd always source control the retrieved dependencies). Google also has internal tooling that utilizes online shared caches in order to build the massive projects that they have. > I know for a fact that Gradle and it's downloading features actually cause serious problems for some of our customers who sit behind restrictive firewalls and have to use complex proxy setups to > reach the Internet. They basically have to circumvent countless company policies just to bootstrap Gradle. > > Besides I somehow doubt that it is even remotely reasonable to mimic a > build system that weights 225 MiB in size. Tools should know their task and focus on that. No need for a kitchen sink. This would be an optional feature that you would by no means be required to use. Mobile developers will definitely want it though. Don't worry, Qt will never require network access to build. > Ciao, > Mathias > > -- > Mathias Hasselmann | mathias.hasselmann at kdab.com | Software Engineer > KDAB (Deutschland) GmbH&Co KG, a KDAB Group company > Tel: +49-30-521325485 / +49-30-521325470 > KDAB - The Qt Experts > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From adam.treat at qt.io Thu Mar 9 20:07:30 2017 From: adam.treat at qt.io (Adam Treat) Date: Thu, 9 Mar 2017 14:07:30 -0500 Subject: [Development] syncqt.pl in C++ In-Reply-To: <1733911.qi4zXjP78C@tjmaciei-mobl1> References: <1733911.qi4zXjP78C@tjmaciei-mobl1> Message-ID: <1817a63e-008c-0d58-e893-75a35d1b9ad9@qt.io> On 03/07/2017 03:54 PM, Thiago Macieira wrote: > Same here, though I have also to concede that breaking the status quo (to > quote Jake's tweet) is sometimes a good idea. Teambuilder -- to name another > Trolltech project that had nothing to do with qt -- was a couple of orders of > magnitude better than the tools that existed at the time (distcc). Icecream/ > icecc came about only because TB wasn't open source, but every now and then I > miss TB2 features that icecc doesn't have. TB3 would have been even better. > > Maybe qbs will be another such leapfrog. I can't fault TQtC for trying. Speaking of distributed compilers... if QBS had built-in icecream/TeamBuilder like functionality I would *love* this. It could even bundle the tarball itself since it has the complete recipe for all the tools necessary, the translation unit and everything in addition to create the object file. That'd be one compelling feature for me. From egor.pugin at gmail.com Thu Mar 9 21:19:51 2017 From: egor.pugin at gmail.com (Egor Pugin) Date: Thu, 9 Mar 2017 23:19:51 +0300 Subject: [Development] syncqt.pl in C++ In-Reply-To: <1817a63e-008c-0d58-e893-75a35d1b9ad9@qt.io> References: <1733911.qi4zXjP78C@tjmaciei-mobl1> <1817a63e-008c-0d58-e893-75a35d1b9ad9@qt.io> Message-ID: Hello again, Pretty long discussion is moved to build systems. Here are some my general notes and brief presentation of my project. 1. For those who may be interested - my simple implementation of syncqt.pl in C++ available here [1]. Works for me, tested and compiled core, gui, widgets, prepared all other headers. Feel free to use it for any purpose and contact me if you need. 2. Build systems. Obvious BS candidate for many projects is cmake. We see that it can handle big projects well (LLVM). Don't know much about Qbs, but if will be (is) productive and extensible enough it may be useful. Some other less spread build systems introduce heavy dependencies (like python). 3. > The general idea is kind of following that of the Gradle wrapper, where any project that uses the Gradle build system also can include a standard wrapper script which obtains and bootstraps the build system itself before building your project, allowing ANY project based on that build system to be "zero dependencies". git clone & go, the system figures out the rest as much as it can. I'm developing similar system that is based on CMake named C++ Archive Network [2]. That's why I asked the original question. Cppan uses simple declarative (YAML) syntax plus custom cmake insertions. Cppan in some sences is similar to npm, cocoapods and some other language package managers. You point your dependencies to CPPAN and it downloads and bootstraps them for you in any config you requested. You can pass any option or link flags to all deps. They are able to inherit everything if you want to. Static/shared/mt/md/32/64/different MSVCs/compilers/cmake generators (including ninja - WIP)/build caching and much more included. As a result we get simple crosscompiling. CPPAN is crossplatform, handles package versions, dependencies, namespaces. You can register there and add your package. As PoC I've added tons of c/c++ world libraries and now it's Qt time [3,4]. qt.base.core, gui and widgets are added and working. I'm very close to single-shot (one command) building of simple widget apps (QML is just a question of time - few weeks). One-shotting of projects (building, installing, testing, your fav workflow here) is the main goal. Almost all of those packages are in 'pvt.cppan.demo' namespace. For official purposes org.* com.* could be used. E.g. org.qtproject.qt.*, org.boost.*, com.intel.* etc. They are similar to Java, C#? namespaces. More info you can find on the site. Good doc is still in progress. As not a toy project CPPAN is currently used to build tesseract-OCR on Windows [5]. Also cppan is already self-hosted today. [1] https://github.com/egorpugin/syncqt/blob/master/syncqt.cpp [2] https://cppan.org/ [3] https://cppan.org/projects/pvt.cppan.demo.qtproject [4] https://cppan.org/pvt.cppan.demo.qtproject.qt.base.core [5] https://github.com/tesseract-ocr/tesseract -- Egor Pugin On 9 March 2017 at 22:07, Adam Treat wrote: > > > On 03/07/2017 03:54 PM, Thiago Macieira wrote: >> >> Same here, though I have also to concede that breaking the status quo (to >> quote Jake's tweet) is sometimes a good idea. Teambuilder -- to name >> another >> Trolltech project that had nothing to do with qt -- was a couple of orders >> of >> magnitude better than the tools that existed at the time (distcc). >> Icecream/ >> icecc came about only because TB wasn't open source, but every now and >> then I >> miss TB2 features that icecc doesn't have. TB3 would have been even >> better. >> >> Maybe qbs will be another such leapfrog. I can't fault TQtC for trying. > > > Speaking of distributed compilers... if QBS had built-in > icecream/TeamBuilder like functionality I would *love* this. It could even > bundle the tarball itself since it has the complete recipe for all the tools > necessary, the translation unit and everything in addition to create the > object file. > > That'd be one compelling feature for me. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Egor Pugin From corentin.jabot at gmail.com Fri Mar 10 12:03:36 2017 From: corentin.jabot at gmail.com (Corentin) Date: Fri, 10 Mar 2017 11:03:36 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: Message-ID: JSC is pretty slow to build compared to V4. I think It's an inconvenient. And it would negate the efforts to get rid out of QtScript/JSC in Qt. It may be wishful thinking, but it would be great if QBS and Qml could use the exact same engine that would only be build once. Le mer. 8 mars 2017 à 21:10, Jake Petroules a écrit : > I'm working on the qbs bootstrapping. The requirements will be: a C++11 > compiler. End of requirements. Seriously. Not even bash, if you don't mind > typing a couple commands manually. > > Right now we depend on JSC via QtScript (not V4) but that will change at > some point. We're not entirely sure of the solution yet; newer JSC vs V8 vs > V4 or another solution. > > JSC supports ES2017 nowadays so I somewhat favor that. > > Qt could then include a tiny bootstrap script which downloads and > bootstraps qbs, then builds Qt (but the normal use case would be that you > already have qbs installed). > > -- > Jake Petroules - jake.petroules at qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > > ------------------------------ > *From:* Development qt.io at qt-project.org> on behalf of Sune Vuorela > *Sent:* Wednesday, March 8, 2017 11:53:17 AM > *To:* development at qt-project.org > > *Subject:* Re: [Development] syncqt.pl in C++ > On 2017-03-07, Lars Knoll wrote: > > This also makes qbs a natural choice to also use for Qt itself, and I > belie= > > ve all the people that have worked and maintained Qt's build system over > th= > > e last few years are supporting this. Of course this requires that we > can s= > > how that qbs can be used to build Qt. > > I expect this also includes "Can be bootstrapped" and "Does not require > a qbs executable obtained from elsewhere with all dependencies". And > maybe even "Can be built on platforms where v4 isn't yet > ported." > > /Sune > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joerg.bornemann at qt.io Fri Mar 10 13:48:18 2017 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Fri, 10 Mar 2017 13:48:18 +0100 Subject: [Development] syncqt.pl in C++ In-Reply-To: <1529832.zzSgnqPmnO@tjmaciei-mobl1> References: <1529832.zzSgnqPmnO@tjmaciei-mobl1> Message-ID: On 09/03/2017 07:55, Thiago Macieira wrote: > Have you tried the JerryScript interpreter? No, but we have tried Duktape a year ago. I stopped working on a switch to Duktape because of three things: 1. C++-references to JS objects. One had to make sure that the engine doesn't garbage collect what you're referencing. That was possible in a hacky way. 2. Much worse: no way of implementing a QScripClass-like facility. Solvable, for sure, but nothing that's done easily along the way. 3. The insight that if we have to ship a JS engine anyways it can just be QtScript, or a stripped-down version of it for my sake. On 10/03/2017 12:03, Corentin wrote: > JSC is pretty slow to build compared to V4. I think It's an > inconvenient. Do we have numbers for that? Anyways, the usage of JavaScriptCore is conveniently hidden behind the QtScript API. Any JavaScript engine can be plugged into qbs by writing an adapter that provides the subset of QtScript's API qbs uses. BR, Joerg From thiago.macieira at intel.com Fri Mar 10 18:33:40 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 10 Mar 2017 09:33:40 -0800 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: <1529832.zzSgnqPmnO@tjmaciei-mobl1> Message-ID: <1777238.VBcOUkpY3J@tjmaciei-mobl1> On sexta-feira, 10 de março de 2017 04:48:18 PST Joerg Bornemann wrote: > No, but we have tried Duktape a year ago. > I stopped working on a switch to Duktape because of three things: > 1. C++-references to JS objects. One had to make sure that the engine > doesn't garbage collect what you're referencing. That was possible in a > hacky way. > 2. Much worse: no way of implementing a QScripClass-like facility. > Solvable, for sure, but nothing that's done easily along the way. > 3. The insight that if we have to ship a JS engine anyways it can just > be QtScript, or a stripped-down version of it for my sake. Except that QtScript has a very old JSC engine that hasn't received security updates, or any updates of any kind, for some time. It would be irresponsible to use it for new projects. Find another, please. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at qt.io Fri Mar 10 20:08:21 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Fri, 10 Mar 2017 19:08:21 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: <1777238.VBcOUkpY3J@tjmaciei-mobl1> References: <1529832.zzSgnqPmnO@tjmaciei-mobl1> <1777238.VBcOUkpY3J@tjmaciei-mobl1> Message-ID: <2CE75540-19C1-40A9-9089-48A529EAC52B@qt.io> > On Mar 10, 2017, at 9:33 AM, Thiago Macieira wrote: > > On sexta-feira, 10 de março de 2017 04:48:18 PST Joerg Bornemann wrote: >> No, but we have tried Duktape a year ago. >> I stopped working on a switch to Duktape because of three things: >> 1. C++-references to JS objects. One had to make sure that the engine >> doesn't garbage collect what you're referencing. That was possible in a >> hacky way. >> 2. Much worse: no way of implementing a QScripClass-like facility. >> Solvable, for sure, but nothing that's done easily along the way. >> 3. The insight that if we have to ship a JS engine anyways it can just >> be QtScript, or a stripped-down version of it for my sake. > > Except that QtScript has a very old JSC engine that hasn't received security > updates, or any updates of any kind, for some time. It would be irresponsible > to use it for new projects. > > Find another, please. We never said we will continue to use QtScript *as-is*. When I said JSC, I was talking about a modern version of JSC from the WebKit trunk, not the last copy of it that was bundled with QtScript. For standards-compliance & features, JSC is quite attractive as it's the most advanced. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From apoenitz at t-online.de Fri Mar 10 20:21:38 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 10 Mar 2017 20:21:38 +0100 Subject: [Development] syncqt.pl in C++ In-Reply-To: <2CE75540-19C1-40A9-9089-48A529EAC52B@qt.io> References: <1529832.zzSgnqPmnO@tjmaciei-mobl1> <1777238.VBcOUkpY3J@tjmaciei-mobl1> <2CE75540-19C1-40A9-9089-48A529EAC52B@qt.io> Message-ID: <20170310192138.GA1857@klara.mpi.htwm.de> On Fri, Mar 10, 2017 at 07:08:21PM +0000, Jake Petroules wrote: > We never said we will continue to use QtScript *as-is*. When I said JSC, I was > talking about a modern version of JSC from the WebKit trunk, not the last copy > of it that was bundled with QtScript. For standards-compliance & features, JSC > is quite attractive as it's the most advanced. I don't think compliance to a standard carries a lot of weight in a context where said language is typically used in half-line stanzas embedded in a non-standardized container format. Thinking about it, *none* of the original reasons to use JS as embedded scripting language carries a lot of weight as far as I am concerned. Andre' From Jake.Petroules at qt.io Fri Mar 10 20:56:18 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Fri, 10 Mar 2017 19:56:18 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: <20170310192138.GA1857@klara.mpi.htwm.de> References: <1529832.zzSgnqPmnO@tjmaciei-mobl1> <1777238.VBcOUkpY3J@tjmaciei-mobl1> <2CE75540-19C1-40A9-9089-48A529EAC52B@qt.io> <20170310192138.GA1857@klara.mpi.htwm.de> Message-ID: <4BE4AD2C-689B-4131-AD0E-CDFD28A932E8@qt.io> > On Mar 10, 2017, at 11:21 AM, André Pönitz wrote: > > On Fri, Mar 10, 2017 at 07:08:21PM +0000, Jake Petroules wrote: >> We never said we will continue to use QtScript *as-is*. When I said JSC, I was >> talking about a modern version of JSC from the WebKit trunk, not the last copy >> of it that was bundled with QtScript. For standards-compliance & features, JSC >> is quite attractive as it's the most advanced. > > I don't think compliance to a standard carries a lot of weight in a context > where said language is typically used in half-line stanzas embedded in a > non-standardized container format. If you think that, you haven't seen the qbs source code. We have thousands of lines of JavaScript code in dozens of separate files which are referenced from QML, and I expect that to grow by an order of magnitude in the long term. We try to separate the declarative parts from the imperative parts as much as possible; once it goes over a certain line length, it goes to a JS file. > Thinking about it, *none* of the original reasons to use JS as embedded > scripting language carries a lot of weight as far as I am concerned. > Andre' -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From thiago.macieira at intel.com Sat Mar 11 17:02:58 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 11 Mar 2017 08:02:58 -0800 Subject: [Development] syncqt.pl in C++ In-Reply-To: <2CE75540-19C1-40A9-9089-48A529EAC52B@qt.io> References: <1777238.VBcOUkpY3J@tjmaciei-mobl1> <2CE75540-19C1-40A9-9089-48A529EAC52B@qt.io> Message-ID: <5369861.C96lbXXUnk@tjmaciei-mobl1> On sexta-feira, 10 de março de 2017 11:08:21 PST Jake Petroules wrote: > We never said we will continue to use QtScript *as-is*. When I said JSC, I > was talking about a modern version of JSC from the WebKit trunk, not the > last copy of it that was bundled with QtScript. For standards-compliance & > features, JSC is quite attractive as it's the most advanced. So you're basically ressurrecting QtScript? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From denis.shienkov at gmail.com Sun Mar 12 15:23:53 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Sun, 12 Mar 2017 17:23:53 +0300 Subject: [Development] Use RAII for non-pointer resources Message-ID: Hi all, what do you think about using of RAII, e.g. for: * Windows: for HANDLE, HKEY and so on. * POSIX: for fd and so on. * OSX: for io_registry_entry_t and so on. ?? As we use C++11 now everywhere, then, maybe can be to add appropriate RAII functionality e.g. to qcore_unix_p.h, qcore_win_p.h, qcore_mac_p.h files? Please see: [1] http://stackoverflow.com/questions/22775500/is-there-any-raii-file-handle-already-implemented [2] http://stackoverflow.com/questions/24611215/one-liner-for-raii-on-non-pointer [3] http://stackoverflow.com/questions/14841396/stdunique-ptr-deleters-and-the-win32-api and soo on. :) BR, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Sun Mar 12 20:13:16 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 12 Mar 2017 22:13:16 +0300 Subject: [Development] Use RAII for non-pointer resources In-Reply-To: References: Message-ID: <8077551489345996@web17g.yandex.ru> 12.03.2017, 17:24, "Denis Shienkov" : > Hi all, > > what do you think about using of RAII, e.g. for: > > * Windows: for HANDLE, HKEY and so on. > * POSIX: for fd and so on. > * OSX: for io_registry_entry_t and so on. > > ?? > > As we use C++11 now everywhere, then, maybe can be to add appropriate > RAII functionality e.g. to qcore_unix_p.h, qcore_win_p.h, qcore_mac_p.h files? Note that unique_ptr with custom deleter is not a good fit for non-pointer resources. Better approach is discussed here: https://accu.org/index.php/journals/2086 > > Please see: > > [1] http://stackoverflow.com/questions/22775500/is-there-any-raii-file-handle-already-implemented > [2] http://stackoverflow.com/questions/24611215/one-liner-for-raii-on-non-pointer > [3] http://stackoverflow.com/questions/14841396/stdunique-ptr-deleters-and-the-win32-api > > and soo on. :) > > BR, > Denis > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From oswald.buddenhagen at qt.io Mon Mar 13 12:33:32 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 13 Mar 2017 12:33:32 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201703011338.47378.marc.mutz@kdab.com> References: <201703011338.47378.marc.mutz@kdab.com> Message-ID: <20170313113332.GP19298@troll08> On Wed, Mar 01, 2017 at 01:38:47PM +0100, Marc Mutz wrote: > On Wednesday 01 March 2017 13:13:17 Lars Knoll wrote: > > > Let’s conclude this topic now by moving on towards 5.9 as Tuukka > > > proposed. After some thinking I also agree that this is the best > > > course of action from where we are right now. > > > > This also implies that bug fixes should now get pushed to the 5.9 > > branch and we should close the 5.8 branch soon. > > I disagree. Even if you cannot produce releases from 5.8 anymore, > that's our stable branch. > that may be the case, but doesn't necessarily mean that you need to upstream your fixes there. closing it only affects other users of the 5.8 tip who want your fixes. probably not that many. otoh, the branch being open costs CI cycles and causes some forward merging effort, while benefitting a marginal number of people. another point is that most tqtc employees are actually following the management order and are neglecting 5.8 (for two months now), which means that it's by far not as stable as one would want it to be. so i guess it's time to give in and officially close the branch. From sean.harmer at kdab.com Mon Mar 13 22:03:29 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 13 Mar 2017 21:03:29 +0000 Subject: [Development] Problem pushing to 5.9 branch Message-ID: <7c099cc8-7cba-9486-31fe-d21b1f8b0ff9@kdab.com> Hi, is there some problem with gerrit? I don't seem to be able to push to the 5.9 branch at the moment. Thanks, Sean From sean.harmer at kdab.com Mon Mar 13 22:07:42 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 13 Mar 2017 21:07:42 +0000 Subject: [Development] Problem pushing to 5.9 branch In-Reply-To: <7c099cc8-7cba-9486-31fe-d21b1f8b0ff9@kdab.com> References: <7c099cc8-7cba-9486-31fe-d21b1f8b0ff9@kdab.com> Message-ID: Ah, never mind. I'm on a new machine and forgot to set something up. False alarm. Sean On 13/03/2017 21:03, Sean Harmer wrote: > Hi, > > is there some problem with gerrit? I don't seem to be able to push to > the 5.9 branch at the moment. > > Thanks, > > Sean > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Simon.Hausmann at qt.io Tue Mar 14 10:33:44 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 14 Mar 2017 09:33:44 +0000 Subject: [Development] Use of std::function in Qt API Message-ID: Hi, I understand that there are limitations (to put it mildly) regarding the use of API from the C++ standard library in Qt API itself due to the inability to extend our binary compatibility promise. I'm curious though whether std::function falls under the same umbrella? I understand that we permit the use of std::function in Windows specific API of QProcess, which may or may not be different. However I'm curious about this in the context of API that is intended to be fully cross-platform. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Tue Mar 14 11:32:39 2017 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 14 Mar 2017 11:32:39 +0100 Subject: [Development] Use of std::function in Qt API In-Reply-To: References: Message-ID: <24435701.t0Ygg1vmXa@maurice> On Dienstag, 14. März 2017 10:33:44 CET Simon Hausmann wrote: > Hi, > > > I understand that there are limitations (to put it mildly) regarding the use > of API from the C++ standard library in Qt API itself due to the inability > to extend our binary compatibility promise. I'm curious though whether > std::function falls under the same umbrella? Yes, it does: the binary representation (including size), or the mangling is not guaranteed to be the same across stdlib implementations. So here are the choice: 1- Re-implement QFunction, with similar semantic as std::function. 2- Lift the constraint that we can't use the stdlib in our ABI 3- Do nothing and keep using awkward interface when we need callback. #3 is, as usual, the easier (status quo) and will probably happen. #1 is a somewhat difficult task, but not that hard. We will just end up with a poor copy of std::function. #2 was always dismissed in the past, but I think it should be seriously considered. (The same applies to std::unique_ptr, too) > I understand that we permit the use of std::function in Windows specific API > of QProcess, which may or may not be different. However I'm curious about > this in the context of API that is intended to be fully cross-platform. Actually, this is breaking the policy. Even on Windows, there are different std lib implementations. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From marc.mutz at kdab.com Tue Mar 14 14:49:30 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 14 Mar 2017 14:49:30 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <20170313113332.GP19298@troll08> References: <201703011338.47378.marc.mutz@kdab.com> <20170313113332.GP19298@troll08> Message-ID: <201703141449.31178.marc.mutz@kdab.com> On Monday 13 March 2017 12:33:32 Oswald Buddenhagen wrote: > On Wed, Mar 01, 2017 at 01:38:47PM +0100, Marc Mutz wrote: > > On Wednesday 01 March 2017 13:13:17 Lars Knoll wrote: > > > > Let’s conclude this topic now by moving on towards 5.9 as Tuukka > > > > proposed. After some thinking I also agree that this is the best > > > > course of action from where we are right now. > > > > > > This also implies that bug fixes should now get pushed to the 5.9 > > > branch and we should close the 5.8 branch soon. > > > > I disagree. Even if you cannot produce releases from 5.8 anymore, > > that's our stable branch. > > that may be the case, but doesn't necessarily mean that you need to > upstream your fixes there. closing it only affects other users of the > 5.8 tip who want your fixes. probably not that many. All Linux distributions, unless they decide to skip 5.8 completely, due to lack of upstream support? > otoh, the branch being open costs CI cycles and causes some forward > merging effort, while benefitting a marginal number of people. > > another point is that most tqtc employees are actually following the > management order and are neglecting 5.8 (for two months now), which > means that it's by far not as stable as one would want it to be. > > so i guess it's time to give in and officially close the branch. Hurray for Open Governance... -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From olivier at woboq.com Tue Mar 14 15:23:06 2017 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 14 Mar 2017 15:23:06 +0100 Subject: [Development] syncqt.pl in C++ In-Reply-To: References: <1817a63e-008c-0d58-e893-75a35d1b9ad9@qt.io> Message-ID: <2037833.htozhWlMGi@maurice> On Donnerstag, 9. März 2017 21:19:51 CET Egor Pugin wrote: > Hello again, > > Pretty long discussion is moved to build systems. > Here are some my general notes and brief presentation of my project. > > 1. For those who may be interested - my simple implementation of > syncqt.pl in C++ available here [1]. Works for me, tested and compiled > core, gui, widgets, prepared all other headers. Feel free to use it > for any purpose and contact me if you need. > [1] https://github.com/egorpugin/syncqt/blob/master/syncqt.cpp You are replacing a perl dependency by a boost one. I'm not sure which one is worse. Also, I don't see the implementation of enumerate_files (is it in the files that seem to be missing) So in order to go upstream we need to, at least: get rid of the boost dependency, and integrate so it can be built and run by the configure script. (Also it should compile with all supported compiler, that includes GCC 4.8 which did not have std::regex IIRC) > 2. Build systems. Obvious BS candidate for many projects is cmake. We > see that it can handle big projects well (LLVM). Don't know much about > Qbs, but if will be (is) productive and extensible enough it may be > useful. Some other less spread build systems introduce heavy > dependencies (like python). About build system, I saw that Qt6 is mentioned. However, I would like to point out that a change in the build system is orthogonal to a change in the major version. I mean: We can change the Qt build system in any version of Qt we don't have to wait Qt6 for that. As long as qmake stays working for applications using it, of course. But then again, we can deprecate qmake within Qt5 life time (we did it with QtScript/ QtWebkit) Also, different modules could use different build system (That's already the case for qtwebengine) -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From marc.mutz at kdab.com Tue Mar 14 15:29:00 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 14 Mar 2017 15:29:00 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <20170313113332.GP19298@troll08> References: <201703011338.47378.marc.mutz@kdab.com> <20170313113332.GP19298@troll08> Message-ID: <201703141529.01099.marc.mutz@kdab.com> On Monday 13 March 2017 12:33:32 Oswald Buddenhagen wrote: > neglecting 5.8 (for two months now) $ git log --ancestry-path 'gerrit/5.8@{2 month ago}..gerrit/5.8' \ --oneline | wc -l 402 $ git log --ancestry-path 'gerrit/5.9@{2 month ago}..gerrit/5.9' \ --oneline | wc -l warning: Log for 'gerrit/5.9' only goes back to Mon, 13 Feb 2017 12:08:20 195 $ git log --ancestry-path \ 'gerrit/5.8@{Mon, 13 Feb 2017 12:08:20 +0100}..gerrit/5.8' \ --oneline | wc -l 153 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Tue Mar 14 16:47:11 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 14 Mar 2017 08:47:11 -0700 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201703141529.01099.marc.mutz@kdab.com> References: <20170313113332.GP19298@troll08> <201703141529.01099.marc.mutz@kdab.com> Message-ID: <7320456.XNjE60DIOc@tjmaciei-mobl1> On terça-feira, 14 de março de 2017 07:29:00 PDT Marc Mutz wrote: > On Monday 13 March 2017 12:33:32 Oswald Buddenhagen wrote: > > neglecting 5.8 (for two months now) > > $ git log --ancestry-path 'gerrit/5.8@{2 month ago}..gerrit/5.8' \ > --oneline | wc -l > 402 > $ git log --ancestry-path 'gerrit/5.9@{2 month ago}..gerrit/5.9' \ > --oneline | wc -l > warning: Log for 'gerrit/5.9' only goes back to Mon, 13 Feb 2017 12:08:20 > 195 > $ git log --ancestry-path \ > 'gerrit/5.8@{Mon, 13 Feb 2017 12:08:20 +0100}..gerrit/5.8' \ > --oneline | wc -l > 153 You're using the reflog, which implies how often you update your gerrit remote, not the commits in question. For the last two months: [qtbase] $ git rev-list --no-merges --since=2.months.ago v5.8.0..origin/5.8 | wc -l 335 $ git rev-list --no-merges --since=2.months.ago origin/5.8..origin/5.9 | wc -l 276 $ git rev-list --no-merges --since=2.months.ago origin/5.9..origin/dev | wc -l 72 So, no, at this point qtbase has more activity in 5.8 than 5.9. [qtdeclarative] $ git rev-list --no-merges --since=2.months.ago v5.8.0..origin/5.8 | wc -l 60 $ git rev-list --no-merges --since=2.months.ago origin/5.8..origin/5.9 | wc -l 210 $ git rev-list --no-merges --since=2.months.ago origin/5.9..origin/dev | wc -l 63 The situation is reversed in qtdeclarative. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Mar 14 16:54:06 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 14 Mar 2017 08:54:06 -0700 Subject: [Development] Use of std::function in Qt API In-Reply-To: References: Message-ID: <5906332.WhEB48GCMy@tjmaciei-mobl1> On terça-feira, 14 de março de 2017 02:33:44 PDT Simon Hausmann wrote: > Hi, > > > I understand that there are limitations (to put it mildly) regarding the use > of API from the C++ standard library in Qt API itself due to the inability > to extend our binary compatibility promise. I'm curious though whether > std::function falls under the same umbrella? It does. libstdc++ has shown they have no qualms about breaking binary compatibility in downstream libraries, as they've done it twice in the past three releases (the most notable case was std::string). What we have to ask ourselves is whether we want to say that is not our problem. For example, the std::string breakage caused any application or library that used it in its API to need to be recompiled. Besides Qt, there aren't many libraries that avoid it. So if the underlying C++ Standard Library breaks ABI, should we try to work around it? Or should we punt the problem to the user? There's also the case of libc++ and libstdc++ mixing. That used to be a macOS question, but it's nowadays mostly a Linux question. However, unlike macOS, Linux distributors and developers using libc++ don't know how to do it properly, so libc++ and libstdc++ can't be *actually* mixed, as they don't share the low-level ABI. If that is going to remain as is, then mixing is not possible anyway and ceases to be a use-case for us. > I understand that we permit the use of std::function in Windows specific API > of QProcess, which may or may not be different. However I'm curious about > this in the context of API that is intended to be fully cross-platform. Now that MSVC 2017 does retain binary compatibility with 2015, we have to revisit that position if Microsoft starts using inline namespaces to break ABI. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Mar 14 16:54:53 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 14 Mar 2017 08:54:53 -0700 Subject: [Development] Use of std::function in Qt API In-Reply-To: <24435701.t0Ygg1vmXa@maurice> References: <24435701.t0Ygg1vmXa@maurice> Message-ID: <2119809.X5V4NlTABQ@tjmaciei-mobl1> On terça-feira, 14 de março de 2017 03:32:39 PDT Olivier Goffart wrote: > > I understand that we permit the use of std::function in Windows specific > > API of QProcess, which may or may not be different. However I'm curious > > about this in the context of API that is intended to be fully > > cross-platform. > Actually, this is breaking the policy. Even on Windows, there are different > std lib implementations. There's exactly one stdlib implementation per compiler ABI. You were not allowed to mix them anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ville.voutilainen at gmail.com Tue Mar 14 17:01:25 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Tue, 14 Mar 2017 18:01:25 +0200 Subject: [Development] Use of std::function in Qt API In-Reply-To: <5906332.WhEB48GCMy@tjmaciei-mobl1> References: <5906332.WhEB48GCMy@tjmaciei-mobl1> Message-ID: On 14 March 2017 at 17:54, Thiago Macieira wrote: >> I understand that there are limitations (to put it mildly) regarding the use >> of API from the C++ standard library in Qt API itself due to the inability >> to extend our binary compatibility promise. I'm curious though whether >> std::function falls under the same umbrella? > > It does. libstdc++ has shown they have no qualms about breaking binary > compatibility in downstream libraries, as they've done it twice in the past > three releases (the most notable case was std::string). Ahem, it's not like there weren't qualms about it, but doing it for std::string and std::list was eventually necessary. The libstdc++ developers (including myself) spend fair amounts of time and energy trying to avoid abi breakage, including abi breakage in downstream libraries. > What we have to ask ourselves is whether we want to say that is not our > problem. For example, the std::string breakage caused any application or > library that used it in its API to need to be recompiled. Besides Qt, there > aren't many libraries that avoid it. So if the underlying C++ Standard Library > breaks ABI, should we try to work around it? Or should we punt the problem to > the user? I don't know. What do our users want? How big a problem would it be for them? From thiago.macieira at intel.com Tue Mar 14 17:19:42 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 14 Mar 2017 09:19:42 -0700 Subject: [Development] Use of std::function in Qt API In-Reply-To: References: <5906332.WhEB48GCMy@tjmaciei-mobl1> Message-ID: <10891277.V59VZiCxk5@tjmaciei-mobl1> On terça-feira, 14 de março de 2017 09:01:25 PDT Ville Voutilainen wrote: > Ahem, it's not like there weren't qualms about it, but doing it for > std::string and std::list > was eventually necessary. The libstdc++ developers (including myself) > spend fair amounts > of time and energy trying to avoid abi breakage, including abi > breakage in downstream libraries. I know, and we're grateful for 7 years of no breakage. It was good while it lasted. But then it happened, as we all knew it would. And then it happened again, in a separate release, instead of everything in one release. The cxxabi people also keep a document about a v2 of the ABI itself, so that will happen some day. > > What we have to ask ourselves is whether we want to say that is not our > > problem. For example, the std::string breakage caused any application or > > library that used it in its API to need to be recompiled. Besides Qt, > > there > > aren't many libraries that avoid it. So if the underlying C++ Standard > > Library breaks ABI, should we try to work around it? Or should we punt > > the problem to the user? > > I don't know. What do our users want? How big a problem would it be for > them? Right. See also the libc++/libstdc++ mix, which Linux distributions have not, after years of shipping libc++, done properly. So it seems like mixnig is not a desired use-case. Given that, I'm beginning to think that we should change our policy. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at qt.io Tue Mar 14 17:30:00 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 14 Mar 2017 16:30:00 +0000 Subject: [Development] Use of std::function in Qt API In-Reply-To: <10891277.V59VZiCxk5@tjmaciei-mobl1> References: <5906332.WhEB48GCMy@tjmaciei-mobl1> , <10891277.V59VZiCxk5@tjmaciei-mobl1> Message-ID: <1EC534C9-39C3-4202-825C-C9DBCF8B2253@qt.io> I feel the same: Let's limit our binary compatibility promise to the part that we can control. That would be Qt itself. Anyone attempting to build a system with a wider scope of binary compatibility promises needs to also control the shipment of other components, such as libstdc++/libc++, libgcc and others. Simon > On 14 Mar 2017, at 17:20, Thiago Macieira wrote: > >> On terça-feira, 14 de março de 2017 09:01:25 PDT Ville Voutilainen wrote: >> Ahem, it's not like there weren't qualms about it, but doing it for >> std::string and std::list >> was eventually necessary. The libstdc++ developers (including myself) >> spend fair amounts >> of time and energy trying to avoid abi breakage, including abi >> breakage in downstream libraries. > > I know, and we're grateful for 7 years of no breakage. It was good while it > lasted. > > But then it happened, as we all knew it would. And then it happened again, in > a separate release, instead of everything in one release. > > The cxxabi people also keep a document about a v2 of the ABI itself, so that > will happen some day. > >>> What we have to ask ourselves is whether we want to say that is not our >>> problem. For example, the std::string breakage caused any application or >>> library that used it in its API to need to be recompiled. Besides Qt, >>> there >>> aren't many libraries that avoid it. So if the underlying C++ Standard >>> Library breaks ABI, should we try to work around it? Or should we punt >>> the problem to the user? >> >> I don't know. What do our users want? How big a problem would it be for >> them? > > Right. See also the libc++/libstdc++ mix, which Linux distributions have not, > after years of shipping libc++, done properly. So it seems like mixnig is not > a desired use-case. > > Given that, I'm beginning to think that we should change our policy. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From apoenitz at t-online.de Tue Mar 14 18:33:15 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Tue, 14 Mar 2017 18:33:15 +0100 Subject: [Development] Use of std::function in Qt API In-Reply-To: <5906332.WhEB48GCMy@tjmaciei-mobl1> References: <5906332.WhEB48GCMy@tjmaciei-mobl1> Message-ID: <20170314173315.GA13182@klara.mpi.htwm.de> On Tue, Mar 14, 2017 at 08:54:06AM -0700, Thiago Macieira wrote: > On terça-feira, 14 de março de 2017 02:33:44 PDT Simon Hausmann wrote: > > Hi, > > > > > > I understand that there are limitations (to put it mildly) regarding the use > > of API from the C++ standard library in Qt API itself due to the inability > > to extend our binary compatibility promise. I'm curious though whether > > std::function falls under the same umbrella? > > It does. libstdc++ has shown they have no qualms about breaking binary > compatibility in downstream libraries, as they've done it twice in the past > three releases (the most notable case was std::string). > > What we have to ask ourselves is whether we want to say that is not our > problem. For example, the std::string breakage caused any application or > library that used it in its API to need to be recompiled. Besides Qt, there > aren't many libraries that avoid it. So if the underlying C++ Standard Library > breaks ABI, should we try to work around it? Or should we punt the problem to > the user? The main point here is "besides Qt, there aren't many libraries that avoid it", and that's, fortunately or not, very true. In practice people do typically not expect a C++ application surviving Standard Library ABI breakages without recompilation. In general, I am not overly sold on ABI compatibility promises. I personally could live without and find SC of more practical value. The most important "feature" of ABI compatibility guarantee for me is that it limits people from doing overly excessive source-incompatible changes. I wouldn't go all-in at once, but by now the advantages of allowing std::function in the Qt API outweigh any potential gains of not using it by far, so "punt the problem to the user" sound just fine to me, also when wearing a user's hat. Andre' From marc.mutz at kdab.com Tue Mar 14 20:57:24 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 14 Mar 2017 20:57:24 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <7320456.XNjE60DIOc@tjmaciei-mobl1> References: <201703141529.01099.marc.mutz@kdab.com> <7320456.XNjE60DIOc@tjmaciei-mobl1> Message-ID: <201703142057.24647.marc.mutz@kdab.com> On Tuesday 14 March 2017 16:47:11 Thiago Macieira wrote: [...] > So, no, at this point qtbase has more activity in 5.8 than 5.9. [...] So, how about at least releasing a qtbase-only 5.8.1? :) -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From egor.pugin at gmail.com Tue Mar 14 21:50:34 2017 From: egor.pugin at gmail.com (Egor Pugin) Date: Tue, 14 Mar 2017 23:50:34 +0300 Subject: [Development] syncqt.pl in C++ In-Reply-To: <2037833.htozhWlMGi@maurice> References: <1817a63e-008c-0d58-e893-75a35d1b9ad9@qt.io> <2037833.htozhWlMGi@maurice> Message-ID: > You are replacing a perl dependency by a boost one. I'm not sure which one is worse. That is reference implementation only. It's far far away of needed shape to replace the perl script. Some functions (enumerate_files) were taken from other libraries including boost. On 14 March 2017 at 17:23, Olivier Goffart wrote: > On Donnerstag, 9. März 2017 21:19:51 CET Egor Pugin wrote: >> Hello again, >> >> Pretty long discussion is moved to build systems. >> Here are some my general notes and brief presentation of my project. >> >> 1. For those who may be interested - my simple implementation of >> syncqt.pl in C++ available here [1]. Works for me, tested and compiled >> core, gui, widgets, prepared all other headers. Feel free to use it >> for any purpose and contact me if you need. >> [1] https://github.com/egorpugin/syncqt/blob/master/syncqt.cpp > > You are replacing a perl dependency by a boost one. I'm not sure which one is > worse. > Also, I don't see the implementation of enumerate_files (is it in the > files that seem to be missing) > > So in order to go upstream we need to, at least: get rid of the boost > dependency, and integrate so it can be built and run by the configure script. > > (Also it should compile with all supported compiler, that includes GCC 4.8 > which did not have std::regex IIRC) > >> 2. Build systems. Obvious BS candidate for many projects is cmake. We >> see that it can handle big projects well (LLVM). Don't know much about >> Qbs, but if will be (is) productive and extensible enough it may be >> useful. Some other less spread build systems introduce heavy >> dependencies (like python). > > About build system, I saw that Qt6 is mentioned. > However, I would like to point out that a change in the build system is > orthogonal to a change in the major version. > I mean: We can change the Qt build system in any version of Qt we don't have > to wait Qt6 for that. > As long as qmake stays working for applications using it, of course. But then > again, we can deprecate qmake within Qt5 life time (we did it with QtScript/ > QtWebkit) > > Also, different modules could use different build system (That's already the > case for qtwebengine) > > > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - https://code.woboq.org -- Egor Pugin From michalrz at socialbicycles.com Wed Mar 15 10:04:36 2017 From: michalrz at socialbicycles.com (=?UTF-8?Q?Micha=c5=82_'Khorne'_Lowas-Rzechonek?=) Date: Wed, 15 Mar 2017 10:04:36 +0100 Subject: [Development] Bug in qtimageformats WBMP plugin Message-ID: Hi, I know that WBMP is not a popular format since WAP is long dead, but in our application it's useful for transferring small bitmaps over a serial bus. I've noticed there is a bug in the implementation when the bitmap dimensions are multiples of 128. In such cases, variable-length integer should be encoded as 2 bytes, not 1. I've never contributed to Qt so I don't know where am I supposed to send the patch... It's actually very simple: diff --git a/src/plugins/imageformats/wbmp/qwbmphandler.cpp b/src/plugins/imageformats/wbmp/qwbmphandler.cpp index cd9b04a..d2dec87 100644 --- a/src/plugins/imageformats/wbmp/qwbmphandler.cpp +++ b/src/plugins/imageformats/wbmp/qwbmphandler.cpp @@ -81,6 +81,7 @@ static bool readMultiByteInt(QIODevice *iodev, quint32 *num) static bool writeMultiByteInt(QIODevice *iodev, quint32 num) { + quint8 width = 1; quint64 tmp = num & 0x7F; num >>= 7; @@ -88,13 +89,15 @@ static bool writeMultiByteInt(QIODevice *iodev, quint32 num) quint8 c = num & 0x7F; num = num >> 7; tmp = (tmp << 8) | (c | 0x80); + width += 1; } - while (tmp) { + while (width) { quint8 c = tmp & 0xFF; if (!iodev->putChar(c)) return false; tmp >>= 8; + width -= 1; } return true; } cheers -- Michał 'Khorne' Lowas-Rzechonek Social Bicycles Inc. From samuel.gaist at edeltech.ch Wed Mar 15 10:15:46 2017 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Wed, 15 Mar 2017 10:15:46 +0100 Subject: [Development] Bug in qtimageformats WBMP plugin In-Reply-To: References: Message-ID: > On 15 Mar 2017, at 10:04, Michał 'Khorne' Lowas-Rzechonek wrote: > > Hi, > > I know that WBMP is not a popular format since WAP is long dead, but in our application it's useful for transferring small bitmaps over a serial bus. > > I've noticed there is a bug in the implementation when the bitmap dimensions are multiples of 128. In such cases, variable-length integer should be encoded as 2 bytes, not 1. > > I've never contributed to Qt so I don't know where am I supposed to send the patch... It's actually very simple: > > > diff --git a/src/plugins/imageformats/wbmp/qwbmphandler.cpp b/src/plugins/imageformats/wbmp/qwbmphandler.cpp > index cd9b04a..d2dec87 100644 > --- a/src/plugins/imageformats/wbmp/qwbmphandler.cpp > +++ b/src/plugins/imageformats/wbmp/qwbmphandler.cpp > @@ -81,6 +81,7 @@ static bool readMultiByteInt(QIODevice *iodev, quint32 *num) > > static bool writeMultiByteInt(QIODevice *iodev, quint32 num) > { > + quint8 width = 1; > quint64 tmp = num & 0x7F; > num >>= 7; > > @@ -88,13 +89,15 @@ static bool writeMultiByteInt(QIODevice *iodev, quint32 num) > quint8 c = num & 0x7F; > num = num >> 7; > tmp = (tmp << 8) | (c | 0x80); > + width += 1; > } > > - while (tmp) { > + while (width) { > quint8 c = tmp & 0xFF; > if (!iodev->putChar(c)) > return false; > tmp >>= 8; > + width -= 1; > } > return true; > } > > cheers > -- > Michał 'Khorne' Lowas-Rzechonek > Social Bicycles Inc. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > Hi and thanks for contributing ! You can find the documentation here: https://wiki.qt.io/Gerrit_Introduction on how to get up and running with code contributions. Cheers Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From oswald.buddenhagen at qt.io Wed Mar 15 10:49:38 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 15 Mar 2017 10:49:38 +0100 Subject: [Development] Bug in qtimageformats WBMP plugin In-Reply-To: References: Message-ID: <20170315094938.GC11628@ugly> On Wed, Mar 15, 2017 at 10:15:46AM +0100, Samuel Gaist wrote: > You can find the documentation here: > > https://wiki.qt.io/Gerrit_Introduction > > on how to get up and running with code contributions. > https://wiki.qt.io/Qt_Contribution_Guidelines is a better entry point (though personally i'd prefer to strip out all redundancy from it, so it would be a pure landing page). From edward.welbourne at qt.io Wed Mar 15 18:14:39 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 15 Mar 2017 17:14:39 +0000 Subject: [Development] QUIP 0: one QUIP to index them all and from the web-site link them In-Reply-To: <2CA69E2F-3517-44CF-A2DE-C0E61D1DC15D@qt.io> References: <20161110112912.GB9877@troll08> <2537366.LM4OPadTkB@42>,<2CA69E2F-3517-44CF-A2DE-C0E61D1DC15D@qt.io> Message-ID: Hi all, Back in November we had ample discussion of QUIPs, then went off to review several of them, leaving this list quiet. There are now several approaching readiness [0], slightly hampered by the original promulgator of the idea going elsewhere. The foundations are the scripts to turn QUIPs into web pages and the first few QUIPs. Go take a look. [0] https://codereview.qt-project.org/#/q/status:open+project:meta/quips,n,z One current blocker on several QUIPs is finding when they were first mentioned on this mailing list - the date of which should go into the Post-History header. If you know the dates your favourite QUIP got mentioned on the list, you could go to its review and answer my comment on the lack of a Post-History with those dates (in ISO date format). If your pet QUIP hasn't actually *been* mentioned on this mailing list, I encourage you to do so forthwith. In particular, I don't see any mention before now of "QUIP 0", the index page for the QUIPs, which shall be generated by a script but converted to a web page by the same script as acts on QUIPs, so needs a Post-History date - to which end I herewith give notice that this "meta-QUIP" shall indeed exist (so that I can use today's date in that field). It just lists the real QUIPs and is generated by scripts/gen-quip-0000.py (whose revision history shall be used for its Version and Last-Modified headers), which can be found in [1]. The script is only 63 lines of python, so shouldn't be too scary to read. [1] https://codereview.qt-project.org/177657 We still lack a permanent home in which to host the generated HTML form of QUIPs; and we need someone competent at web-design to deal with the HTML/JavaScript/CSS template for it all. Volunteers welcome. See QTQAINFRA-1173 for notes on progress or [1] for the on-going review. Eddy. From marc.mutz at kdab.com Thu Mar 16 10:00:55 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 16 Mar 2017 10:00:55 +0100 Subject: [Development] Need advise on acceptable timeouts for autotests Message-ID: <201703161000.55480.marc.mutz@kdab.com> Hi, We repeatedly have the problem that timeouts that developers think are ample (because they exceed typical runtime by, say, two orders of magnitude) are found to be insufficient on the CI. Latest example: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1489618366 The timeout to run update-mime-database was recently increased to 2mins. But that still does not seem to be enough. For a call that hardly takes a second to run on unloaded machines. We can of course crank up timeouts to insane amounts like 1h, but that means that a test will just sit there idling for an hour in the worst case. I have two questions: 1. Where do these huge slowdowns come from? Is the VM live-migrated? Is the SAN, if any, down? At this point it lools like no overcommitting of CPU/RAM could ever explain how update-mime-database can take 2mins to run. 2. What should we choose as timeouts? I understand that tests which are stuck are killed after some time (how long?). Maybe timeouts should be set to the same value? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From olivier at woboq.com Thu Mar 16 15:03:19 2017 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 16 Mar 2017 15:03:19 +0100 Subject: [Development] Need advise on acceptable timeouts for autotests In-Reply-To: <201703161000.55480.marc.mutz@kdab.com> References: <201703161000.55480.marc.mutz@kdab.com> Message-ID: <13426433.N3I24fZRKM@maurice> On Donnerstag, 16. März 2017 10:00:55 CET Marc Mutz wrote: > Hi, > > We repeatedly have the problem that timeouts that developers think are ample > (because they exceed typical runtime by, say, two orders of magnitude) are > found to be insufficient on the CI. > > Latest example: > http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1489618366 > > The timeout to run update-mime-database was recently increased to 2mins. But > that still does not seem to be enough. For a call that hardly takes a > second to run on unloaded machines. > > We can of course crank up timeouts to insane amounts like 1h, but that means > that a test will just sit there idling for an hour in the worst case. > > I have two questions: > > 1. Where do these huge slowdowns come from? Is the VM live-migrated? Is the > SAN, if any, down? At this point it lools like no overcommitting of > CPU/RAM could ever explain how update-mime-database can take 2mins to run. In this particular case, it seems there is an actual problem with tst_QMimeDatabase, it is broken in every branches because update-mime- database does not stops or stops with errors. Maybe there is a bug in update- mime-database in this particular machine? > 2. What should we choose as timeouts? I understand that tests which are > stuck are killed after some time (how long?). Maybe timeouts should be set > to the same value? It should be set to a shorter value -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From Simon.Hausmann at qt.io Thu Mar 16 15:04:20 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 16 Mar 2017 14:04:20 +0000 Subject: [Development] Need advise on acceptable timeouts for autotests In-Reply-To: <201703161000.55480.marc.mutz@kdab.com> References: <201703161000.55480.marc.mutz@kdab.com> Message-ID: Hi, (1) We don't know where the slowdowns come from. There is no VM migration involved in the CI (the license does not include this feature). There is a SAN under every single virtual machine disk (something we are getting rid of in the not-for-qt-5.8.1 time). (2) I don't know what the correct choice of a timeout here is. The current logic for dealing with timeouts for tests in qtbase is quite simple: (a) The total time "make check" is allowed to take when it is run in each sub-directory is 15 minutes (but I think that there are exceptions). (b) While the test is running, if no output appears in stderr or stdout within the course of 20 minutes, a timeout error is raised. Any output appearing resets this 20-minute timer back to zero. Simon ________________________________ From: marc at kdab.com on behalf of Marc Mutz Sent: Thursday, March 16, 2017 10:00:55 AM To: development at qt-project.org Cc: Qt CI Subject: Need advise on acceptable timeouts for autotests Hi, We repeatedly have the problem that timeouts that developers think are ample (because they exceed typical runtime by, say, two orders of magnitude) are found to be insufficient on the CI. Latest example: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1489618366 The timeout to run update-mime-database was recently increased to 2mins. But that still does not seem to be enough. For a call that hardly takes a second to run on unloaded machines. We can of course crank up timeouts to insane amounts like 1h, but that means that a test will just sit there idling for an hour in the worst case. I have two questions: 1. Where do these huge slowdowns come from? Is the VM live-migrated? Is the SAN, if any, down? At this point it lools like no overcommitting of CPU/RAM could ever explain how update-mime-database can take 2mins to run. 2. What should we choose as timeouts? I understand that tests which are stuck are killed after some time (how long?). Maybe timeouts should be set to the same value? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Mar 16 16:36:27 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 16 Mar 2017 08:36:27 -0700 Subject: [Development] Need advise on acceptable timeouts for autotests In-Reply-To: <201703161000.55480.marc.mutz@kdab.com> References: <201703161000.55480.marc.mutz@kdab.com> Message-ID: <1653437.1N3sLIYcbH@tjmaciei-mobl1> Em quinta-feira, 16 de março de 2017, às 02:00:55 PDT, Marc Mutz escreveu: > 2. What should we choose as timeouts? I understand that tests which are > stuck are killed after some time (how long?). Maybe timeouts should be set > to the same value? Just wondering here: is there any way to run the machine inside a time bubble? That is, run its clock slower, so the passage of time inside is slower than the outside. I've never seen it on the VMM software. I don't think it can be done in the OS. But it can easily be done by either: a) LD_PRELOAD / DYLD_PRELOAD intercepting clock_gettime / mach_absolute_time b) inside qelapsedtimer_*.cpp itself. though this may break any tests that rely on external timing (probably the file time tests). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Thu Mar 16 16:50:52 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 16 Mar 2017 16:50:52 +0100 Subject: [Development] Need advise on acceptable timeouts for autotests In-Reply-To: <201703161000.55480.marc.mutz@kdab.com> References: <201703161000.55480.marc.mutz@kdab.com> Message-ID: <201703161650.52915.marc.mutz@kdab.com> On Thursday 16 March 2017 10:00:55 Marc Mutz wrote: > Latest example: > http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1489618366 Since this new seems to fail consistently across all branches, and didn't before, I suspect something went wrong with some new OS image? -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From tony.sarajarvi at qt.io Thu Mar 16 16:53:12 2017 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Thu, 16 Mar 2017 15:53:12 +0000 Subject: [Development] Need advise on acceptable timeouts for autotests In-Reply-To: <201703161000.55480.marc.mutz@kdab.com> References: <201703161000.55480.marc.mutz@kdab.com> Message-ID: Hi 1. We don't know to be frank. The VMs aren't live migrated, the SAN hasn't been proved to be down or even the bottleneck, at least for standard hardware. Apple hardware is another issue, and here SAN seems to either slow down or possibly even break up sometimes. Some Macs slow down to the point that reading or writing to the hard drive goes through the SAN that slows it down to 10 MB/s. I did encounter curl not being able to download a tar ball, but that was on a buggy version of 10.12. The problem behind curl got fixed in 10.12.2. However, I can't confirm or deny if this has happened after that. We also don't over allocate resources. If we have a 20 core server, we assign only 5 x 4vcpu VMs to it, even if hyperthreading shows the host to have 40 cores. However, I just realized a week ago, that provisioning doesn't follow this "rule". If we have maxed out a server, and we launch provisioning for a template that is assigned to that host, we launch the VM to be provisioned there as well. And if we launch 2 or 3 branches simultaneously, there's a possibility that we allocate 6-8 VMs on that 20 core server. It _should_ cope with it easily, but in theory things start to slow down. That's because the VMWare hypervisor allocates all the CPU cycles the guest might need, even if it only uses 1 core in reality. That's because the hypervisor can't know if the guest fully needs all 4 or not. But even if we doubled the amount of VMs on a host, and all of them ran 100%, that would mean that we reduce the amount of CPU cycles in half. Even then an action taking a split second won't take 2 seconds, not to mention 2 minutes. 2 years ago we debugged one of these oddities where network tests failed for no good reason. It looked like vSphere's underlying virtual LAN caused problems dropping packages. However, when debugging, we found out that it was in fact Qt's network code that was buggy. It had something to do with 2 IP packages coming one after another so fast that they both existed in our network code's buffer. But the bug was that only the first one was ever handled. The second one was discarded. At the time no one knew how to fix it, so it was left there. I still don't know if it has been fixed. Someone said that the entire network code should be rewritten, because the current one was a mess. We've also seen GUI tests failing where sleeps seem to help. Here something like waitUntilExposed (or whatever), didn't work as expected in Macs. And obviously this caused problems once or twice in thousands of runs looking like something in the hardware is causing these flaky runs. It is still possible that only certain servers cause these small timing differences. Even likely, since we have lots of servers with several generations between them and repeating these failures on one VM on one host seems to be very difficult when actually starting to debug the tests. But we can't go replacing all the hardware we have in one go and throw away perfectly fine hardware just because it's not identical to the next one. In an ideal world we'd have controlled runs on older and newer generations etc, but in reality I think we have to imagine the hardware being a constant non changing factor beneath the virtualization layer. Broken hardware is another story, and for that we need to gather metrics to see what failed and where. If it's always the same hardware and not even the same generation of hardware, then it's most likely a broken unit. With all that said, I didn't really provide you with any answers did I? :P Regards, -Tony -----Original Message----- From: marc at kdab.com [mailto:marc at kdab.com] On Behalf Of Marc Mutz Sent: torstaina 16. maaliskuuta 2017 11.01 To: development at qt-project.org Cc: Qt CI Subject: Need advise on acceptable timeouts for autotests Hi, We repeatedly have the problem that timeouts that developers think are ample (because they exceed typical runtime by, say, two orders of magnitude) are found to be insufficient on the CI. Latest example: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1489618366 The timeout to run update-mime-database was recently increased to 2mins. But that still does not seem to be enough. For a call that hardly takes a second to run on unloaded machines. We can of course crank up timeouts to insane amounts like 1h, but that means that a test will just sit there idling for an hour in the worst case. I have two questions: 1. Where do these huge slowdowns come from? Is the VM live-migrated? Is the SAN, if any, down? At this point it lools like no overcommitting of CPU/RAM could ever explain how update-mime-database can take 2mins to run. 2. What should we choose as timeouts? I understand that tests which are stuck are killed after some time (how long?). Maybe timeouts should be set to the same value? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From mwoehlke.floss at gmail.com Thu Mar 16 18:23:55 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Thu, 16 Mar 2017 13:23:55 -0400 Subject: [Development] Use of std::function in Qt API In-Reply-To: <20170314173315.GA13182@klara.mpi.htwm.de> References: <5906332.WhEB48GCMy@tjmaciei-mobl1> <20170314173315.GA13182@klara.mpi.htwm.de> Message-ID: <58CACA2B.4040008@gmail.com> On 2017-03-14 13:33, André Pönitz wrote: > In general, I am not overly sold on ABI compatibility promises. I personally > could live without and find SC of more practical value. The most important > "feature" of ABI compatibility guarantee for me is that it limits people from > doing overly excessive source-incompatible changes. Distros are likely to care; a Qt BC break requires a mass rebuild of everything that uses Qt (which translates into lots of users needing to update lots of packages when Qt changes). Distros may refuse to update Qt within a distro release as a result, which means users are stuck with older Qt for longer. All that more or less already applies to the standard library however (probably most distros don't accept a standard library BC break without a mass rebuild anyway), so Qt insulating against BC breaks in the standard library is maybe less necessary. -- Matthew From apoenitz at t-online.de Fri Mar 17 00:26:20 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 17 Mar 2017 00:26:20 +0100 Subject: [Development] Use of std::function in Qt API In-Reply-To: <58CACA2B.4040008@gmail.com> References: <5906332.WhEB48GCMy@tjmaciei-mobl1> <20170314173315.GA13182@klara.mpi.htwm.de> <58CACA2B.4040008@gmail.com> Message-ID: <20170316232619.GC12511@klara.mpi.htwm.de> On Thu, Mar 16, 2017 at 01:23:55PM -0400, Matthew Woehlke wrote: > On 2017-03-14 13:33, André Pönitz wrote: > > In general, I am not overly sold on ABI compatibility promises. I personally > > could live without and find SC of more practical value. The most important > > "feature" of ABI compatibility guarantee for me is that it limits people from > > doing overly excessive source-incompatible changes. > > Distros are likely to care; a Qt BC break requires a mass rebuild of > everything that uses Qt (which translates into lots of users needing to > update lots of packages when Qt changes). I am three steps away from understanding what you are saying: I don't get why a library (Qt or anything else) BC break would cause a distro to update packages outside their usual upgrade cycle (when most, or rather all, of the packages will be recompiled anyway), nor, in case the distro did it nevertheless, do I understand why a user would need to upgrade packages in that case, nor, in case the distro *and* the user consciously decided to upgrade, why that would be a problem. > Distros may refuse to update Qt within a distro release as a result, which means > users are stuck with older Qt for longer. Yes, and, so what? We are not talking about security problems. What is wrong with running a half-year, or worst case maybe even a two year old version of some library as base for the bulk of the applications? > All that more or less already applies to the standard library however (probably > most distros don't accept a standard library BC break without a mass rebuild > anyway), so Qt insulating against BC breaks in the standard library is maybe > less necessary. That was the starting point here. Not Qt breaking BC by itself, but allowing C++ BC breakages to affect otherwise "pure Qt" applications. Andre' From thiago.macieira at intel.com Fri Mar 17 06:39:26 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 16 Mar 2017 22:39:26 -0700 Subject: [Development] Use of std::function in Qt API In-Reply-To: <20170316232619.GC12511@klara.mpi.htwm.de> References: <58CACA2B.4040008@gmail.com> <20170316232619.GC12511@klara.mpi.htwm.de> Message-ID: <1733969.zkWJSR88XI@tjmaciei-mobl1> Em quinta-feira, 16 de março de 2017, às 16:26:20 PDT, André Pönitz escreveu: > On Thu, Mar 16, 2017 at 01:23:55PM -0400, Matthew Woehlke wrote: > > On 2017-03-14 13:33, André Pönitz wrote: > > > In general, I am not overly sold on ABI compatibility promises. I > > > personally could live without and find SC of more practical value. The > > > most important "feature" of ABI compatibility guarantee for me is that > > > it limits people from doing overly excessive source-incompatible > > > changes. > > > > Distros are likely to care; a Qt BC break requires a mass rebuild of > > everything that uses Qt (which translates into lots of users needing to > > update lots of packages when Qt changes). > > I am three steps away from understanding what you are saying: > > I don't get why a library (Qt or anything else) BC break would cause a > distro to update packages outside their usual upgrade cycle (when most, or > rather all, of the packages will be recompiled anyway) Your paretheses is incorrect: not all distros recompile everything at every release. Since libraries keep BC, what has been once compiled can be kept; only what changed needs to be compiled again. Rebuilding the world is an expensive proposition. > , nor, in case the > distro did it nevertheless, do I understand why a user would need to > upgrade packages in that case, Ever heard of bug fixes? That's why users upgrade packages. > nor, in case the distro *and* the user > consciously decided to upgrade, why that would be a problem. Because if there's a BC break, then all the packages linking to that library would need to be upgraded, all at the same time. If every library did this, at uncontrolled points in their releases, every single bugfix would require building everything that changed downstream from it and thus downloading it all and installing. There's also the issue of what happens during that upgrade process, when certain programs will be already running linking to the old library, and may suddenly load plugins that were compiled against the new ABI, causing crashes left and right if you've installed updates until you reboot. And there are also binaries that don't come from distributions. When dealing with developers, it happens often that people have stuff lying around they build a couple of months ago. BC breaks are a recipe for unexpected and hard- to-debug issues. The libstdc++ break showed how developers aren't aware of this issue and keep running into problems. I saw several times people reporting build errors that included "unresolved symbol ". And that was a minor break. > > Distros may refuse to update Qt within a distro release as a result, which > > means users are stuck with older Qt for longer. > > Yes, and, so what? It would be less of a problem if we actually released bugfix releases. We don't. Case in point: 5.8.1. So, no, going from 5.7.1 to 5.8.0 to 5.9.0 to get bugfixes is not acceptable, especially if that implies recompiling half the distro and forcing reboots. > We are not talking about security problems. What is wrong with running a > half-year, or worst case maybe even a two year old version of some library > as base for the bulk of the applications? Because there are worse than or equally bad issues as security problems. For example, during 5.4, all Qt-based applications would crash when I plugged in my external monitor. Without a bugfix, it would mean being unable to *work*. It's bad enough that our policy is "no bugfix for youf or 6 months". It would be worse if it were "and when you get those bugfixes, you need to rebuild everything or download a gigabyte of new builds". > > All that more or less already applies to the standard library however > > (probably most distros don't accept a standard library BC break without a > > mass rebuild anyway), so Qt insulating against BC breaks in the standard > > library is maybe less necessary. > > That was the starting point here. Not Qt breaking BC by itself, but allowing > C++ BC breakages to affect otherwise "pure Qt" applications. Distros did shield from rebuilding after the libstdc++ breakages. But I am with others now saying that we shouldn't have to go out or our way to do that. If libstdc++ does it, it's for a good reason. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ulf.hermann at qt.io Fri Mar 17 10:19:10 2017 From: ulf.hermann at qt.io (Ulf Hermann) Date: Fri, 17 Mar 2017 10:19:10 +0100 Subject: [Development] Use of std::function in Qt API In-Reply-To: <58CACA2B.4040008@gmail.com> References: <5906332.WhEB48GCMy@tjmaciei-mobl1> <20170314173315.GA13182@klara.mpi.htwm.de> <58CACA2B.4040008@gmail.com> Message-ID: <0777a7eb-407b-5800-885a-9cc3abf0adcc@qt.io> > All that more or less already applies to the standard library however > (probably most distros don't accept a standard library BC break without > a mass rebuild anyway), so Qt insulating against BC breaks in the > standard library is maybe less necessary. This is the important observation. Hardly anyone (actually, is there anyone besides Qt?) guarantees resilience against standard library BC breakages. So, if the standard library breaks BC and the distribution accepts the new version, then it doesn't really matter what Qt does with it as all packages that use the standard library, including ones that also use Qt, will have to be rebuilt. C++ packages that don't use the standard library are rather rare. Let's just allow standard library types in Qt, and document that the BC guarantee only extends across compatible standard libraries. Ulf From viktor.engelmann at qt.io Fri Mar 17 10:32:57 2017 From: viktor.engelmann at qt.io (Viktor Engelmann) Date: Fri, 17 Mar 2017 10:32:57 +0100 Subject: [Development] Use of std::function in Qt API In-Reply-To: <1733969.zkWJSR88XI@tjmaciei-mobl1> References: <58CACA2B.4040008@gmail.com> <20170316232619.GC12511@klara.mpi.htwm.de> <1733969.zkWJSR88XI@tjmaciei-mobl1> Message-ID: On 17.03.2017 06:39, Thiago Macieira wrote: > Em quinta-feira, 16 de março de 2017, às 16:26:20 PDT, André Pönitz escreveu: >> On Thu, Mar 16, 2017 at 01:23:55PM -0400, Matthew Woehlke wrote: >>> On 2017-03-14 13:33, André Pönitz wrote: >>>> In general, I am not overly sold on ABI compatibility promises. I >>>> personally could live without and find SC of more practical value. The >>>> most important "feature" of ABI compatibility guarantee for me is that >>>> it limits people from doing overly excessive source-incompatible >>>> changes. >>> Distros are likely to care; a Qt BC break requires a mass rebuild of >>> everything that uses Qt (which translates into lots of users needing to >>> update lots of packages when Qt changes). ... >> nor, in case the distro *and* the user >> consciously decided to upgrade, why that would be a problem. > Because if there's a BC break, then all the packages linking to that library > would need to be upgraded, all at the same time. If every library did this, at > uncontrolled points in their releases, every single bugfix would require > building everything that changed downstream from it and thus downloading it > all and installing. >> That was the starting point here. Not Qt breaking BC by itself, but allowing >> C++ BC breakages to affect otherwise "pure Qt" applications. > Distros did shield from rebuilding after the libstdc++ breakages. But I am > with others now saying that we shouldn't have to go out or our way to do that. > If libstdc++ does it, it's for a good reason. I see some valid concerns here, but I think in practice, André is right. We are talking about BC breakages that happen because of libstdc++ BC breakages. If distros switch from one libstdc++ to a binary incompatible libstdc++ *between releases*, then it's their own fault they have to rebuild and redeliver everything. And if they don't, then qt libs don't break BC either, so there is no problem in that case. I think it might be wisest to allow BC breakage under the premise that the major version number must change whenever BC is broken. That would tell people loud and clear that they have to rebuild (also the library names are likely to change then, so old versions of a program can't accidentally load the binary incompatible library) -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin Viktor.Engelmann at qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Tobias.Hunger at qt.io Fri Mar 17 10:43:05 2017 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Fri, 17 Mar 2017 09:43:05 +0000 Subject: [Development] Use of std::function in Qt API In-Reply-To: <58CACA2B.4040008@gmail.com> References: <5906332.WhEB48GCMy@tjmaciei-mobl1> <20170314173315.GA13182@klara.mpi.htwm.de> <58CACA2B.4040008@gmail.com> Message-ID: <1489743782.984.18.camel@qt.io> On Thu, 2017-03-16 at 13:23 -0400, Matthew Woehlke wrote: > On 2017-03-14 13:33, André Pönitz wrote: > > In general, I am not overly sold on ABI compatibility promises. I personally > > could live without and find SC of more practical value. The most important > > "feature" of ABI compatibility guarantee for me is that it limits people > > from > > doing overly excessive source-incompatible changes. > > Distros are likely to care; a Qt BC break requires a mass rebuild of > everything that uses Qt (which translates into lots of users needing to > update lots of packages when Qt changes). Distros may refuse to update > Qt within a distro release as a result, which means users are stuck with > older Qt for longer. I think this is not a real issue: A distribution will not update the standard c++ library within a distro release. Neither will a distribution upgrade Qt minor versions within a distro release. I do not expect patch version upgrades of Qt to introduce BC issues with or without it relying on std::functionality. Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From marc.mutz at kdab.com Fri Mar 17 11:31:23 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 17 Mar 2017 11:31:23 +0100 Subject: [Development] Use of std::function in Qt API In-Reply-To: <0777a7eb-407b-5800-885a-9cc3abf0adcc@qt.io> References: <58CACA2B.4040008@gmail.com> <0777a7eb-407b-5800-885a-9cc3abf0adcc@qt.io> Message-ID: <201703171131.23545.marc.mutz@kdab.com> On Friday 17 March 2017 10:19:10 Ulf Hermann wrote: > Let's just allow standard library types in Qt, and document that the BC > guarantee only extends across compatible standard libraries. The Qt BC guarantee should only cover Qt. It should explicitly exclude compiler switches, libc, stdlib, boost, libclang, ... libraries. IOW: Qt guarantees that: 1. two different patch releases of the same Qt minor release are binary compatible with each other, and 2. that a younger minor release is binary compatible with any older minor release of the same major Qt release, provided the same external libraries, and the same toolchain are used to build the two Qt releases. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Fri Mar 17 17:16:39 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 17 Mar 2017 09:16:39 -0700 Subject: [Development] Use of std::function in Qt API In-Reply-To: <201703171131.23545.marc.mutz@kdab.com> References: <0777a7eb-407b-5800-885a-9cc3abf0adcc@qt.io> <201703171131.23545.marc.mutz@kdab.com> Message-ID: <2659294.2lXc8mz1WK@tjmaciei-mobl1> Em sexta-feira, 17 de março de 2017, às 03:31:23 PDT, Marc Mutz escreveu: > provided the same external libraries, and the same toolchain are used to > build the two Qt releases. The problem is this line here. People expect to upgrade other libraries. We should say that we guarantee our ABI provided that libc and the C++ library guarantee it too. We won't expose any other library's types in our ABI. But please note how the libstdc++ break was both source-compatible and binary- compatible for the direct users of that library, but caused BC breaks downstream. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Mar 17 17:17:08 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 17 Mar 2017 09:17:08 -0700 Subject: [Development] Use of std::function in Qt API In-Reply-To: <1489743782.984.18.camel@qt.io> References: <58CACA2B.4040008@gmail.com> <1489743782.984.18.camel@qt.io> Message-ID: <2430069.jXMyhJeDhh@tjmaciei-mobl1> Em sexta-feira, 17 de março de 2017, às 02:43:05 PDT, Tobias Hunger escreveu: > A distribution will not update the standard c++ library within a distro > release. > Neither will a distribution upgrade Qt minor versions within a > distro release. Both assertions are incorrect. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Fri Mar 17 17:25:04 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 17 Mar 2017 12:25:04 -0400 Subject: [Development] Use of std::function in Qt API In-Reply-To: <20170316232619.GC12511@klara.mpi.htwm.de> References: <5906332.WhEB48GCMy@tjmaciei-mobl1> <20170314173315.GA13182@klara.mpi.htwm.de> <58CACA2B.4040008@gmail.com> <20170316232619.GC12511@klara.mpi.htwm.de> Message-ID: <58CC0DE0.5040409@gmail.com> On 2017-03-16 19:26, André Pönitz wrote: > On Thu, Mar 16, 2017 at 01:23:55PM -0400, Matthew Woehlke wrote: >> On 2017-03-14 13:33, André Pönitz wrote: >>> In general, I am not overly sold on ABI compatibility promises. I personally >>> could live without and find SC of more practical value. The most important >>> "feature" of ABI compatibility guarantee for me is that it limits people from >>> doing overly excessive source-incompatible changes. >> >> Distros are likely to care; a Qt BC break requires a mass rebuild of >> everything that uses Qt (which translates into lots of users needing to >> update lots of packages when Qt changes). > > I am three steps away from understanding what you are saying: > > I don't get why a library (Qt or anything else) BC break would cause a distro to > update packages outside their usual upgrade cycle (when most, or rather all, of > the packages will be recompiled anyway) 1. You assume that distros never update packages outside of distro updates? 2. What about rolling distros? > nor, in case the distro did it nevertheless, do I understand why a > user would need to upgrade packages in that case, nor, in case the > distro *and* the user consciously decided to upgrade, why that would > be a problem. Addressed in Thiago's reply. >> Distros may refuse to update Qt within a distro release as a result, which means >> users are stuck with older Qt for longer. > > Yes, and, so what? > > We are not talking about security problems. What is wrong with running a > half-year, or worst case maybe even a two year old version of some library > as base for the bulk of the applications? No bug fixes? No new features? Inability to update applications that need the new features? Delay in developers being able to use new features because their users don't have the latest version? >> All that more or less already applies to the standard library however (probably >> most distros don't accept a standard library BC break without a mass rebuild >> anyway), so Qt insulating against BC breaks in the standard library is maybe >> less necessary. > > That was the starting point here. Not Qt breaking BC by itself, but allowing C++ > BC breakages to affect otherwise "pure Qt" applications. Right. My point is I think it's okay for Qt to not bend over backwards to insulate its users from BC breakages of Qt's dependencies (in particular, the C++ standard library), since the efficacy of that "shielding" is debatable. I don't think it's okay to extend that to license for Qt to break *its own, internal BC*, which is what your previous post seemed to be implying. On 2017-03-17 05:32, Viktor Engelmann wrote: > We are talking about BC breakages that happen because of libstdc++ > BC breakages. Are we? That wasn't at all obvious from André's previous message. > I think it might be wisest to allow BC breakage under the premise that > the major version number must change whenever BC is broken. We already do that. (We also allow SC breaks between major versions.) -- Matthew From mwoehlke.floss at gmail.com Fri Mar 17 17:27:27 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 17 Mar 2017 12:27:27 -0400 Subject: [Development] Use of std::function in Qt API In-Reply-To: <2430069.jXMyhJeDhh@tjmaciei-mobl1> References: <58CACA2B.4040008@gmail.com> <1489743782.984.18.camel@qt.io> <2430069.jXMyhJeDhh@tjmaciei-mobl1> Message-ID: <58CC0E6F.6080803@gmail.com> On 2017-03-17 12:17, Thiago Macieira wrote: > Em sexta-feira, 17 de março de 2017, às 02:43:05 PDT, Tobias Hunger escreveu: >> A distribution will not update the standard c++ library within a distro >> release. >> Neither will a distribution upgrade Qt minor versions within a >> distro release. > > Both assertions are incorrect. What Thiago said. Also, FWIW, I prefer when distros *are* willing to make minor-version updates to libraries even within the same release of the distro. (Provided of course such updates don't have breaking changes.) Also, if Qt gets into a habit of skipping bug fix releases, distros may get more pressure to do just that in order to get important bug fixes. -- Matthew From marc.mutz at kdab.com Fri Mar 17 21:02:36 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 17 Mar 2017 21:02:36 +0100 Subject: [Development] Use of std::function in Qt API In-Reply-To: <2659294.2lXc8mz1WK@tjmaciei-mobl1> References: <201703171131.23545.marc.mutz@kdab.com> <2659294.2lXc8mz1WK@tjmaciei-mobl1> Message-ID: <201703172102.37195.marc.mutz@kdab.com> On Friday 17 March 2017 17:16:39 Thiago Macieira wrote: > Em sexta-feira, 17 de março de 2017, às 03:31:23 PDT, Marc Mutz escreveu: > > provided the same external libraries, and the same toolchain are used to > > build the two Qt releases. > The problem is this line here. People expect to upgrade other libraries. > We should say that we guarantee our ABI provided that libc and the C++ > library guarantee it too. We won't expose any other library's types in our > ABI. This is false already today. Or only true for a definition of "libc" that approximates "all libraries Qt depends on". We use Mac types in the ABI. We probably use Windows types in the ABI. We provide platform-native handles, for one. We expose OpenSSL in our ABI. Yes, we hide it behind a void* Qt::HANDLE, but any user of QSslCertificate::handle() already depends on OpenSSL. This is a SEP. Don't insist on making all libraries' ABI stability _our_ problem. If it wasn't for this rule, QSslCertificate::handle() could return the real thing, depending on the platform, saving the user the need to write dangerous casts. Let's say it like this: ... provided the libraries, toolchain and build settings (incl. compiler switches) provide binary compatibility, too. iow: Qt will not introduce spurious binary incompatibilites not already present in libraries, toolchains and settings Qt depends on. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Fri Mar 17 21:12:57 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 17 Mar 2017 13:12:57 -0700 Subject: [Development] Use of std::function in Qt API In-Reply-To: <201703172102.37195.marc.mutz@kdab.com> References: <2659294.2lXc8mz1WK@tjmaciei-mobl1> <201703172102.37195.marc.mutz@kdab.com> Message-ID: <1556042.WIkds205jq@tjmaciei-mobl1> Em sexta-feira, 17 de março de 2017, às 13:02:36 PDT, Marc Mutz escreveu: > On Friday 17 March 2017 17:16:39 Thiago Macieira wrote: > > Em sexta-feira, 17 de março de 2017, às 03:31:23 PDT, Marc Mutz escreveu: > > > provided the same external libraries, and the same toolchain are used to > > > build the two Qt releases. > > > > The problem is this line here. People expect to upgrade other libraries. > > We should say that we guarantee our ABI provided that libc and the C++ > > library guarantee it too. We won't expose any other library's types in our > > ABI. > > This is false already today. Or only true for a definition of "libc" that > approximates "all libraries Qt depends on". Actually, I meant what I said but I realise that it's not accurate. I was going to say "our dependencies", but I wanted to constrain what we actually do expose. We depend on libdoubleconversion and libpcre2, but those aren't exposed in the API. But what I constrained to is inaccurate. > We use Mac types in the ABI. We > probably use Windows types in the ABI. We provide platform-native handles, > for one. Right. And specialised libraries like QX11Extras also expose Xlib types. > We expose OpenSSL in our ABI. Yes, we hide it behind a void* > Qt::HANDLE, but any user of QSslCertificate::handle() already depends on > OpenSSL. This is a SEP. Right, and QDBusConnection also provides a void* to get the DBusConnection, but I've warned that it may change. Note that exposing a void* actually means we *don't* depend on their ABI and, if they break it, our ABI isn't affected. The code inside network/ssl or dbus can deal with the apparent breakage and hide the problem, if necessary. > Don't insist on making all libraries' ABI stability > _our_ problem. If it wasn't for this rule, QSslCertificate::handle() could > return the real thing, depending on the platform, saving the user the need > to write dangerous casts. I'd insist we keep it a void* (I invite you to take a look at qsslcertificate_winrt.cpp) the same way that the native event filter also does type-erasure. Converting back to the original type is SEP. > Let's say it like this: > > ... provided the libraries, toolchain and build settings (incl. compiler > switches) provide binary compatibility, too. Agreed, but I want a whitelist of libraries whose ABI we expose in our ABI. Libraries that are mere backends of what we implement should not be exposed. > iow: Qt will not introduce spurious binary incompatibilites not already > present in libraries, toolchains and settings Qt depends on. Agreed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Mar 17 21:20:38 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 17 Mar 2017 13:20:38 -0700 Subject: [Development] Use of std::function in Qt API In-Reply-To: <58CC0DE0.5040409@gmail.com> References: <20170316232619.GC12511@klara.mpi.htwm.de> <58CC0DE0.5040409@gmail.com> Message-ID: <8614024.MCD9Qxltcv@tjmaciei-mobl1> Em sexta-feira, 17 de março de 2017, às 09:25:04 PDT, Matthew Woehlke escreveu: > > We are not talking about security problems. What is wrong with running a > > half-year, or worst case maybe even a two year old version of some library > > as base for the bulk of the applications? > > No bug fixes? No new features? Inability to update applications that > need the new features? Delay in developers being able to use new > features because their users don't have the latest version? I completely agree on the bug fix issue: bug fixes are required. Before Qt 5.8, our habit was of releasing one or two patch releases, then stopping update and telling people to upgrade to the next minor. It's irresponsible to not provide an update path: we must provide patches to releases we're telling people to use. If we're saying "it's ok for you to stay in that year-old minor series", then we have to provide patches for it. Conversely, if we close that minor series' branch and tell users to upgrade, then they must be able to upgrade without rebuilding the world. 5.6 comes in to help, but we've already been irresponsible in not releasing 5.8.1 again. Our track record is not good. As for the features, I take a middle-road: if a distribution has as policy not updating across minor versions for anything, then nothing requires new features in the first place. Just bugfixes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ville.voutilainen at gmail.com Sat Mar 18 09:06:09 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Sat, 18 Mar 2017 10:06:09 +0200 Subject: [Development] QList Message-ID: There's been a fair amount of talk about QList's future, so I'm curious: 1) What are the problems with QList? 2) What do we plan to do about those problems? 3) How do we expect to migrate code that uses it? Pardons all around for not being up to date if there's some material on the points above; feel free to point me to such material. From annulen at yandex.ru Sat Mar 18 09:54:16 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 18 Mar 2017 11:54:16 +0300 Subject: [Development] QList In-Reply-To: References: Message-ID: <780161489827256@web24m.yandex.ru> 18.03.2017, 11:06, "Ville Voutilainen" : > There's been a fair amount of talk about QList's future, so I'm curious: > > 1) What are the problems with QList? https://marcmutz.wordpress.com/effective-qt/containers/#containers-qlist > 2) What do we plan to do about those problems? This is probably accurate: http://lists.qt-project.org/pipermail/development/2015-July/022283.html > 3) How do we expect to migrate code that uses it? > > Pardons all around for not being up to date if there's some material > on the points > above; feel free to point me to such material. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From rjvbertin at gmail.com Sat Mar 18 10:27:54 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sat, 18 Mar 2017 10:27:54 +0100 Subject: [Development] applications dropping keyboard input Message-ID: <2406425.BpbWke4HcW@bola> Hi, I'm seeing an issue with certain Qt5 applications on Linux that is probably caused by something on such a low level that it seems more appropriate to ask on the development than on the "interest" ML. I'm not sure if it's a Qt or rather a KF5 issue but I'm beginning to think it must be the former. The symptom is that periodically applications stop responding to the keyboard. This is almost always while I'm active with the keyboard, I cannot recall for instance having come back to the system and find the keyboard muted in my absence. Until yesterday I had only seen it in the Qt5-based Konsole application, i.e. the longest-running application with which I interact almost exclusively via the keyboard. Sometimes the whole app would be affect (i.e. all windows and tabs), sometimes only a single tab. In all cases the situation sorts itself when I restart the app (or simply open a new tab). I've seen it too on a much smaller number of occasions the KDE4 Konsole. Yesterday's episode gave me 3 new observations: - it started after I had opened a document in a running KDevelop5 session, from a Konsole5 application. The keyboard input stopped after a few keystrokes, in BOTH KDevelop and all windows of the parent Konsole process. Until now I had only seen this in Konsole itself so I assumed it was a Konsole issue. Clearly it's happening on a lower level. - banging long enough on the keyboard an occasional keystroke would get through. - changing keyboard layouts had no effect (session-wide or in Konsole), nor had restarting KWin (why would it), a suspend/wake cycle or cycling among virtual consoles. I did end up with a wonky keyboard layout though; I use the "English (Macintosh)" layout and lost the AltGr deadkey function in all Qt apps but not in GTK-based apps (i.e. AltGr+e,e would give me ´e instead of é). Usually I get out of that particular situation by toggling the layout to and from Fr but that didn't help here and the French layout was instable too. I had to restart the X server to sort that out. I *think* I never noticed this on my previous notebook but only on the current model, an Intel N3150-based Clevo W5108 . That means I've seen it with Qt 5.5 and later, and kernel 4.5.x and later. Does this ring any bells? Any suggestions what I could look into or try next time this happens? It happens infrequently enough (fortunately) and too randomly to make it appealing to run with qDebug output enabled but if there's nothing else I could try to activate it for Konsole only for a while. (This cannot be done for already running applications, right?) Thanks, R. http://www.mail-archive.com/kde at mail.kde.org/msg04352.html From marc.mutz at kdab.com Sat Mar 18 10:51:06 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 18 Mar 2017 10:51:06 +0100 Subject: [Development] QList In-Reply-To: References: Message-ID: <201703181051.07307.marc.mutz@kdab.com> On Saturday 18 March 2017 09:06:09 Ville Voutilainen wrote: > There's been a fair amount of talk about QList's future, so I'm curious: > > 1) What are the problems with QList? See Konstantin's reply. For me, the performance issue is pretty strong already, but that stability of references into QLists may depend on such subtleties as the machine's word size or whether Q_DECLARE_TYPEINFO has been called for the type is also a big correctness issue. > 2) What do we plan to do about those problems? Kill QList in Qt 6. > 3) How do we expect to migrate code that uses it? Possibly provide a QArrayList that _always_ uses the heap, and thus _always_ provides stability of references. There's some code that actually depends on stability of references (QToolBox, e.g.). Try to minimize use in new code. That hasn't worked out as planned. Look at the dates of my two contributions Konstantin linked to, then look at the API reviews for 5.9. It's almost guarateed that Q_DECLARE_TYPEINFO (or the similar Q_DECLARE_SHARED) have been "forgotten". Review regularly fails for such things. This experience, over several years, has thaught me that we need a technical solution. And so we started to specialize QList as an empty class. So far, this is the only workable solution I have found, and believe me, I am very determined. I think we should do this for all new (non-polymorphic) classes. And since we now depend on enough C++11, replacing QList with QVector in generic code is trivial: either use auto, or when you can't, use QListOrVector, introduced here: https://codereview.qt-project.org/188858 So, here's my proposal for a QList exit strategy: In Qt 5: 1. Replace QList in generic code by QListOrVector, tell users to hold QLists they get from Qt API only in type-deduced variables. 2. Fix any QList API missing (and not actively harmful) on QVector. E.g. I don't think toSet() should be either on QList nor QVector, because it creates nonsense like qHash(QItemSelectionRange) (please, please, look it up :) 3. Disable QList for all new QFoo value types (by specializing QList as an empty class). 4. Provide QArrayList for code that needs stability of references (stability statically checked in Qt 5, enforced in Qt 6). In Qt 6: 5. Replace all QList uses left with ... what ? QVector? std::vector? -> separate discussion 6. Kill QList or keep it as a deprecated class. Thanks, Marc > Pardons all around for not being up to date if there's some material > on the points > above; feel free to point me to such material. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From ville.voutilainen at gmail.com Sat Mar 18 11:25:12 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Sat, 18 Mar 2017 12:25:12 +0200 Subject: [Development] QList In-Reply-To: <201703181051.07307.marc.mutz@kdab.com> References: <201703181051.07307.marc.mutz@kdab.com> Message-ID: On 18 March 2017 at 11:51, Marc Mutz wrote: > On Saturday 18 March 2017 09:06:09 Ville Voutilainen wrote: >> There's been a fair amount of talk about QList's future, so I'm curious: >> >> 1) What are the problems with QList? > > See Konstantin's reply. For me, the performance issue is pretty strong > already, but that stability of references into QLists may depend on such > subtleties as the machine's word size or whether Q_DECLARE_TYPEINFO has been > called for the type is also a big correctness issue. Ah, so there are correctness problems in addition to performance problems. >> 2) What do we plan to do about those problems? > > Kill QList in Qt 6. How much valid code will that break? How many bugs does that avoid? > This experience, over several years, has thaught me that we need a technical > solution. And so we started to specialize QList as an empty class. > So far, this is the only workable solution I have found, and believe me, I am > very determined. As a technical point, reminding me of how std::hash is 'poisoned', and why std::experimental::fundamentals_v2::nonesuch exists, you might want to also prevent default construction, copy/move construction and copy/move assignment. Otherwise an innocent user might create an object of such a type, pass it into a generic function and get a fairly unwelcoming error deep in an instantiation chain. > And since we now depend on enough C++11, replacing QList with QVector in > generic code is trivial: either use auto, or when you can't, use > QListOrVector, introduced here: https://codereview.qt-project.org/188858 Urgh. I can't say I'm a fan of functions that vary their return type based on the characteristics of a template parameter. Nor am I a big fan of "auto everywhere". But both might be a necessary evil to provide a migration path that avoids code breakage. > So, here's my proposal for a QList exit strategy: > > In Qt 5: > > 1. Replace QList in generic code by QListOrVector, tell users to hold QLists > they get from Qt API only in type-deduced variables. In other words, introduce generic code where there wasn't generic code before - users writing non-generic code calling non-templates that return QLists will need to use deduction or a metaprogramming tool. > 2. Fix any QList API missing (and not actively harmful) on QVector. E.g. I > don't think toSet() should be either on QList nor QVector, because it > creates nonsense like qHash(QItemSelectionRange) (please, please, look it > up :) > 3. Disable QList for all new QFoo value types (by specializing QList as > an empty class). > 4. Provide QArrayList for code that needs stability of references (stability > statically checked in Qt 5, enforced in Qt 6). It seems that (4) is perfectly safe, whereas (2) and (3) are breaking changes; to what extent, I would like to know. > In Qt 6: > > 5. Replace all QList uses left with ... what ? QVector? std::vector? > -> separate discussion > 6. Kill QList or keep it as a deprecated class. This certainly seems feasible, but the migration and the extent of it its interesting. There's a fair bunch of QList-using code out there, afaik. From philwave at gmail.com Sat Mar 18 11:25:30 2017 From: philwave at gmail.com (Philippe) Date: Sat, 18 Mar 2017 11:25:30 +0100 Subject: [Development] QList In-Reply-To: <201703181051.07307.marc.mutz@kdab.com> References: <201703181051.07307.marc.mutz@kdab.com> Message-ID: <20170318112529.7CE9.6F0322A@gmail.com> >> For me, the performance issue is pretty strong QVector is not always the best solution here. With QList, insertion and sorting will be faster for containers of large objects, as there is less memory to move around. QList is not to put to the trash. Philippe On Sat, 18 Mar 2017 10:51:06 +0100 Marc Mutz wrote: > On Saturday 18 March 2017 09:06:09 Ville Voutilainen wrote: > > There's been a fair amount of talk about QList's future, so I'm curious: > > > > 1) What are the problems with QList? > > See Konstantin's reply. For me, the performance issue is pretty strong > already, but that stability of references into QLists may depend on such > subtleties as the machine's word size or whether Q_DECLARE_TYPEINFO has been > called for the type is also a big correctness issue. > > > 2) What do we plan to do about those problems? > > Kill QList in Qt 6. > > > 3) How do we expect to migrate code that uses it? > > Possibly provide a QArrayList that _always_ uses the heap, and thus _always_ > provides stability of references. There's some code that actually depends on > stability of references (QToolBox, e.g.). > > Try to minimize use in new code. That hasn't worked out as planned. Look at > the dates of my two contributions Konstantin linked to, then look at the API > reviews for 5.9. It's almost guarateed that Q_DECLARE_TYPEINFO (or the similar > Q_DECLARE_SHARED) have been "forgotten". Review regularly fails for such > things. > > This experience, over several years, has thaught me that we need a technical > solution. And so we started to specialize QList as an empty class. > So far, this is the only workable solution I have found, and believe me, I am > very determined. > > I think we should do this for all new (non-polymorphic) classes. > > And since we now depend on enough C++11, replacing QList with QVector in > generic code is trivial: either use auto, or when you can't, use > QListOrVector, introduced here: https://codereview.qt-project.org/188858 > > So, here's my proposal for a QList exit strategy: > > In Qt 5: > > 1. Replace QList in generic code by QListOrVector, tell users to hold QLists > they get from Qt API only in type-deduced variables. > 2. Fix any QList API missing (and not actively harmful) on QVector. E.g. I > don't think toSet() should be either on QList nor QVector, because it > creates nonsense like qHash(QItemSelectionRange) (please, please, look it > up :) > 3. Disable QList for all new QFoo value types (by specializing QList as > an empty class). > 4. Provide QArrayList for code that needs stability of references (stability > statically checked in Qt 5, enforced in Qt 6). > > In Qt 6: > > 5. Replace all QList uses left with ... what ? QVector? std::vector? > -> separate discussion > 6. Kill QList or keep it as a deprecated class. > > Thanks, > Marc > > > Pardons all around for not being up to date if there's some material > > on the points > > above; feel free to point me to such material. > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From apoenitz at t-online.de Sat Mar 18 11:41:02 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sat, 18 Mar 2017 11:41:02 +0100 Subject: [Development] QList In-Reply-To: References: <201703181051.07307.marc.mutz@kdab.com> Message-ID: <20170318104101.GA5907@klara.mpi.htwm.de> On Sat, Mar 18, 2017 at 12:25:12PM +0200, Ville Voutilainen wrote: > > Kill QList in Qt 6. > > How much valid code will that break? Pretty much all user code as QList has been the advocated default container for more than a decade. >How many bugs does that avoid? Probably not many. E.g keeping long-lived references into a Qt container is a rather uncommon pattern. Andre' From apoenitz at t-online.de Sat Mar 18 13:54:20 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sat, 18 Mar 2017 13:54:20 +0100 Subject: [Development] QList In-Reply-To: References: Message-ID: <20170318125420.GB5907@klara.mpi.htwm.de> On Sat, Mar 18, 2017 at 10:06:09AM +0200, Ville Voutilainen wrote: > There's been a fair amount of talk about QList's future, so I'm curious: > > 1) What are the problems with QList? The main problem is that the idea of what Qt is meant to be has changed over time, or, at the very least, is being attempted to be changed by some. Qt was prioritizing application developer convenience over raw performance, making it easier for an application developers to create something working in reasonable time. That included features like consistency in the API and naming in general that made it possible to transfer knowledge of one part of the API to another. This also included recommendations for "one size fits all" usage patterns including default choices for containers. Of course there is no single container that is best for all uses, and never will be. QList is a compromise to provide something with acceptable worst -case behaviour under a "one type needs to fit all" constraint. It is pretty much *never* the best container for any specific task, so it's easy to make QList look bad in 1:1 comparisons in restricted setups but it serves its purpose of not producings pathological results in common cases like appending, prepending, insertion in the middle. > 2) What do we plan to do about those problems? I am afraid "we" needs qualification on this list. It can mean people reading the list, the project, the company, indviduals with a streak of using the pluralis majestatis in normal speech, and more. If it's about decision making: I don't see consensus here, so my expectation would be either "not much", or "whatever the Chief Maintainer decides". > 3) How do we expect to migrate code that uses it? I personally would not like to see much user code migration being necessary. Qt 3 to Qt 4 was a pain, effectively meaning rewrite of large parts of Qt applications. With that lesson learned, Qt 4 to Qt 5 was mostly source compatible, and as far as I am concerned this worked rather well. Aliasing QList to QVector might be a feasible option, or maybe replacing QList implementation by QVector's, and replacing QVector by something not reference-counted. Andre' From marc.mutz at kdab.com Sat Mar 18 18:37:15 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 18 Mar 2017 18:37:15 +0100 Subject: [Development] QList In-Reply-To: References: <201703181051.07307.marc.mutz@kdab.com> Message-ID: <201703181837.16139.marc.mutz@kdab.com> Ville, A word of warning: when it comes to QList, there's a very vocal minority that claims that either QList works perfectly well or else ain't so bad. But afaict, there's consensus between the people who actually count (sorry to be blunt, but Qt is not a democracy, but a meritocracy) that QList as-is currently was a mistake and needs to go in Qt 6. The only difference in opinion is how to cushion the fall. Lars, Thiago: it would be nice if you could confirm (or deny, in case I misinterpreted) the above as soon as you can. Otherwise this thread will derail massively again. On Saturday 18 March 2017 11:25:12 Ville Voutilainen wrote: [...] > > Kill QList in Qt 6. > > How much valid code will that break? How many bugs does that avoid? Tons. Qt uses QList as the default container since Qt 4.0. Before, it used QValueList, a doubly-linked list. Qt has a very bad track record for its default container choice. We do need to think very carefully about an exit strategy, indeed. What I wrote in the mail you quote from was the part that deals with not introducing new uses of QList. We need also deal with existing use, even though we can hope for clang-based refactoring tools to do the bulk of the work. But we simply cannot, in 2020, continue to use a std::vector> as our default container. That's simply ridiculous. > > This experience, over several years, has thaught me that we need a > > technical solution. And so we started to specialize QList as > > an empty class. So far, this is the only workable solution I have found, > > and believe me, I am very determined. > > As a technical point, reminding me of how std::hash is 'poisoned', and > why std::experimental::fundamentals_v2::nonesuch > exists, you might want to also prevent default construction, copy/move > construction and copy/move assignment. > Otherwise an innocent user might create an object of such a type, pass > it into a generic function and > get a fairly unwelcoming error deep in an instantiation chain. Keep that in mind. You'll almost certainly be reviewing any such changes. > > So, here's my proposal for a QList exit strategy: > > > > In Qt 5: > > > > 1. Replace QList in generic code by QListOrVector, tell users to hold > > QLists > > > > they get from Qt API only in type-deduced variables. > > In other words, introduce generic code where there wasn't generic code > before - users writing > non-generic code calling non-templates that return QLists will need to > use deduction or a metaprogramming tool. No, that is false. You can keep using QList for now everywhere you used it so far, in non-generic code. Nothing changes for existing types. And for new types, the compiler will make sure that you don't get away with QList. We do recommened to use auto to receive QLists to avoid having to port these code lines manually come Qt 6. I do not consider auto variables "generic code". > > 2. Fix any QList API missing (and not actively harmful) on QVector. E.g. > > I > > > > don't think toSet() should be either on QList nor QVector, because it > > creates nonsense like qHash(QItemSelectionRange) (please, please, look > > it up :) > > > > 3. Disable QList for all new QFoo value types (by specializing > > QList as > > > > an empty class). > > > > 4. Provide QArrayList for code that needs stability of references > > (stability > > > > statically checked in Qt 5, enforced in Qt 6). > > It seems that (4) is perfectly safe, whereas (2) and (3) are breaking > changes; to what extent, I would like to know. (2) is possibly breaking, yes. We should intercept by deprecating QList::toSet() and re-adding it as a free function. (3) is breaking nothing for existing code, since it only applies to new types. New types don't magically show up in your source code. You have to introduce them yourself. As for existing generic code, it's a source-incompatibility that is accepted, because it can be fixed by using auto variables. Or you don't use the new type at all. I mean, we're not talking about QString here. With very few exceptions, any type we're adding now will not get widespread use before Qt 6, anyway. One exception hopefully being QStringView. > > In Qt 6: > > > > 5. Replace all QList uses left with ... what ? QVector? std::vector? > > > > -> separate discussion > > > > 6. Kill QList or keep it as a deprecated class. > > This certainly seems feasible, but the migration and the extent of it > its interesting. There's a fair bunch > of QList-using code out there, afaik. Indeed, if it was easy, it would have been done long ago. But it's nonetheless absolutely necessary. Q6String will not fit into a QList anymore. QVariant and QModelIndex already don't. And given the extensive use of QVariant in QML/Qt's property system, I don't think anyone can be happy about the per-element memory allocation in QVariantList. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From philwave at gmail.com Sat Mar 18 18:42:31 2017 From: philwave at gmail.com (Philippe) Date: Sat, 18 Mar 2017 18:42:31 +0100 Subject: [Development] QList In-Reply-To: <20170318125420.GB5907@klara.mpi.htwm.de> References: <20170318125420.GB5907@klara.mpi.htwm.de> Message-ID: <20170318184230.96AC.6F0322A@gmail.com> André Pönitz wrote: > Qt was prioritizing application developer convenience over raw performance, > making it easier for an application developers to create something working > in reasonable time. That included features like consistency in the API > and naming in general that made it possible to transfer knowledge of one > part of the API to another. This also included recommendations for "one > size fits all" usage patterns including default choices for containers. Why are you speaking "in the past"?... Is there a consensus that raw performance should now prime over developer convenience? Philippe From thiago.macieira at intel.com Sat Mar 18 19:05:44 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 18 Mar 2017 11:05:44 -0700 Subject: [Development] QList In-Reply-To: References: <201703181051.07307.marc.mutz@kdab.com> Message-ID: <4152187.FA5rFeLXhG@tjmaciei-mobl1> Em sábado, 18 de março de 2017, às 03:25:12 PDT, Ville Voutilainen escreveu: > >> 2) What do we plan to do about those problems? > > > > Kill QList in Qt 6. > > How much valid code will that break? How many bugs does that avoid? A lot. I don't think we can have Qt 6 without a class called "QList". But we can make it be the same as QVector, which is what we want people to use. We can provide QArrayList as a replacement for anyone who needs pointer stability if they can't use QSet or QHash. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Mar 18 19:30:35 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 18 Mar 2017 11:30:35 -0700 Subject: [Development] QList In-Reply-To: <20170318125420.GB5907@klara.mpi.htwm.de> References: <20170318125420.GB5907@klara.mpi.htwm.de> Message-ID: <3812547.VS9TNzUDzq@tjmaciei-mobl1> Em sábado, 18 de março de 2017, às 05:54:20 PDT, André Pönitz escreveu: > Aliasing QList to QVector might be a feasible option, or maybe replacing > QList implementation by QVector's, and replacing QVector by something > not reference-counted. My plan (which is still not discussed properly and not proven to be feasible) is to provide both referece-counted and non-counted versions of QVector, QString and QByteArray. QVector (and, in fact, all the containers) is easy because it's a template in the first place. Performing std::move from QtExclusive::QVector (name to be discussed) to QVector transfers the array and starts the reference counting; std::move in the other direction also transfers if the reference count is still 1, copying otherwise. That allows code like: QVector someFunction() // out-of-line { QtExclusive::QVector vector; [ operate and populate vector ] return vector; // automatic move } in user code: QtExclusive::QVector vector = someFunction(); // automatic move [ mutate some more ] The objecitve is that the mutating code in [] above runs without having the compiler generate superfluous checks for the reference count which we know to be 1 and emit dead code for the detach() function. This allows high- performance code for sections that really need it. Why not std::vector? Because of the ability to put it back into shared mode, which requires the internals between the exclusively-owning and the reference- counting containers to address the data the same way. For QString and QByteArray, it gets a little more difficult because they are not templates. The current thinking -- and again, no proof attempted that this is actually feasible -- is to have: class QStringView - has all the const functions class QString : public QStringView - adds the mutating functions class QtExclusive::QString : public QString The out-of-line code in the exclusive version can override the public functions from QString and mark them noexcept, since the reference count is guaranteed to be 1 (yes, that's a narrow-contract noexcept). More importantly, the inline non-const data() function in the exclusive version can return the pointer without checking for detach(). Hmm... I can actually start this now. Don't need to wait for Qt 6. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Mar 18 19:15:26 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 18 Mar 2017 11:15:26 -0700 Subject: [Development] QList In-Reply-To: <201703181837.16139.marc.mutz@kdab.com> References: <201703181837.16139.marc.mutz@kdab.com> Message-ID: <7341375.cH6AiziBB6@tjmaciei-mobl1> Em sábado, 18 de março de 2017, às 10:37:15 PDT, Marc Mutz escreveu: > Ville, > > A word of warning: when it comes to QList, there's a very vocal minority > that claims that either QList works perfectly well or else ain't so bad. > But afaict, there's consensus between the people who actually count (sorry > to be blunt, but Qt is not a democracy, but a meritocracy) that QList as-is > currently was a mistake and needs to go in Qt 6. The only difference in > opinion is how to cushion the fall. > > Lars, Thiago: it would be nice if you could confirm (or deny, in case I > misinterpreted) the above as soon as you can. Otherwise this thread will > derail massively again. I think we're in agreement. During Qt 5 development, I began the process of rewriting QList so it suffered less from the problems it suffers, but I ran out of time and it was also an impossible task given the requirement to support C++98 at the time (no ). The objective was to make QList a hybrid: a real vector with no overhead for types smaller than 32 bytes, a pointer list otherwise. But as time went by, I don't think that hybrid approach is valid. A vector is simply much better. For Qt 6, I'd like QVector and QList to be the same type -- possibly even interchangeable, so that code that began using QVector in Qt 5 will be able to "return" QList. > > In other words, introduce generic code where there wasn't generic code > > before - users writing > > non-generic code calling non-templates that return QLists will need to > > use deduction or a metaprogramming tool. > > No, that is false. You can keep using QList for now everywhere you used it > so far, in non-generic code. Nothing changes for existing types. And for > new types, the compiler will make sure that you don't get away with QList. > We do recommened to use auto to receive QLists to avoid having to port > these code lines manually come Qt 6. I do not consider auto variables > "generic code". I don't agree with the poisoning. See my comment in the QStringView review. I agree we should teach users to port away from QList, but not hat it's such a terrible class that they have to port right now, before using new functionality. > > > 4. Provide QArrayList for code that needs stability of references > > > (stability > > > > > > statically checked in Qt 5, enforced in Qt 6). > > > > It seems that (4) is perfectly safe, whereas (2) and (3) are breaking > > changes; to what extent, I would like to know. Actually, we can get started in (4) right now. This will allow porting now. > (2) is possibly breaking, yes. We should intercept by deprecating > QList::toSet() and re-adding it as a free function. Isn't that simply std::copy? > (3) is breaking nothing for existing code, since it only applies to new > types. New types don't magically show up in your source code. You have to > introduce them yourself. As for existing generic code, it's a > source-incompatibility that is accepted, because it can be fixed by using > auto variables. Or you don't use the new type at all. I mean, we're not > talking about QString here. With very few exceptions, any type we're adding > now will not get widespread use before Qt 6, anyway. One exception > hopefully being QStringView. It's abou the message it brings. Doing that is telling people to port right away, not when they have the time to do it properly. > Indeed, if it was easy, it would have been done long ago. But it's > nonetheless absolutely necessary. Q6String will not fit into a QList > anymore. QVariant and QModelIndex already don't. And given the extensive > use of QVariant in QML/Qt's property system, I don't think anyone can be > happy about the per-element memory allocation in QVariantList. Aye. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Sat Mar 18 19:46:24 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sat, 18 Mar 2017 19:46:24 +0100 Subject: [Development] QList In-Reply-To: <3812547.VS9TNzUDzq@tjmaciei-mobl1> References: <20170318125420.GB5907@klara.mpi.htwm.de> <3812547.VS9TNzUDzq@tjmaciei-mobl1> Message-ID: <20170318184624.GA7931@klara.mpi.htwm.de> On Sat, Mar 18, 2017 at 11:30:35AM -0700, Thiago Macieira wrote: > Em sábado, 18 de março de 2017, às 05:54:20 PDT, André Pönitz escreveu: > > Aliasing QList to QVector might be a feasible option, or maybe replacing > > QList implementation by QVector's, and replacing QVector by something > > not reference-counted. > > My plan (which is still not discussed properly and not proven to be feasible) > is to provide both referece-counted and non-counted versions of QVector, > QString and QByteArray. > > QVector (and, in fact, all the containers) is easy because it's a template in > the first place. Performing std::move from QtExclusive::QVector (name to be > discussed) to QVector transfers the array and starts the reference counting; > std::move in the other direction also transfers if the reference count is > still 1, copying otherwise. That allows code like: > > QVector someFunction() // out-of-line > { > QtExclusive::QVector vector; > [ operate and populate vector ] > return vector; // automatic move > } > > in user code: > QtExclusive::QVector vector = someFunction(); // automatic move > [ mutate some more ] > > The objecitve is that the mutating code in [] above runs without having the > compiler generate superfluous checks for the reference count which we know to > be 1 and emit dead code for the detach() function. That would pretty much address the biggest issues I currently have with QVector. Andre' From kevin.kofler at chello.at Sat Mar 18 20:04:46 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 18 Mar 2017 20:04:46 +0100 Subject: [Development] QList References: <201703181051.07307.marc.mutz@kdab.com> <4152187.FA5rFeLXhG@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > A lot. I don't think we can have Qt 6 without a class called "QList". But > we can make it be the same as QVector, which is what we want people to > use. So the user code will at least compile (unlike with Marc Mutz's approach), but algorithms that previously completed in O(n) will now complete only in O(mn) (and of course this multiplies on: if you were inserting into a QList in a loop, it goes from O(n²) to O(mn²)), which is kinda ironic for a change designed to "improve performance". Kevin Kofler From ville.voutilainen at gmail.com Sat Mar 18 20:05:59 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Sat, 18 Mar 2017 21:05:59 +0200 Subject: [Development] QList In-Reply-To: <201703181837.16139.marc.mutz@kdab.com> References: <201703181051.07307.marc.mutz@kdab.com> <201703181837.16139.marc.mutz@kdab.com> Message-ID: On 18 March 2017 at 19:37, Marc Mutz wrote: >> In other words, introduce generic code where there wasn't generic code >> before - users writing >> non-generic code calling non-templates that return QLists will need to >> use deduction or a metaprogramming tool. > > No, that is false. You can keep using QList for now everywhere you used it so > far, in non-generic code. Nothing changes for existing types. And for new > types, the compiler will make sure that you don't get away with QList. We do > recommened to use auto to receive QLists to avoid having to port these code > lines manually come Qt 6. I do not consider auto variables "generic code". Right. I, however, do consider them generic code. :) I don't use them when they introduce a possibility that the type I *want* changes to another type. That might well *not* be a case for a QList->somethingelse transition. >> > 3. Disable QList for all new QFoo value types (by specializing >> > QList as >> > >> > an empty class). >> > >> > 4. Provide QArrayList for code that needs stability of references >> > (stability >> > >> > statically checked in Qt 5, enforced in Qt 6). >> >> It seems that (4) is perfectly safe, whereas (2) and (3) are breaking >> changes; to what extent, I would like to know. > > (2) is possibly breaking, yes. We should intercept by deprecating > QList::toSet() and re-adding it as a free function. > > (3) is breaking nothing for existing code, since it only applies to new types. > New types don't magically show up in your source code. You have to introduce > them yourself. As for existing generic code, it's a source-incompatibility > that is accepted, because it can be fixed by using auto variables. Or you Fair enough, but since it's a source-incompatibility, it *is* a breaking change. What, if anything, it really breaks is the important question. >> > In Qt 6: >> > >> > 5. Replace all QList uses left with ... what ? QVector? std::vector? >> > >> > -> separate discussion >> > >> > 6. Kill QList or keep it as a deprecated class. >> >> This certainly seems feasible, but the migration and the extent of it >> its interesting. There's a fair bunch >> of QList-using code out there, afaik. > > Indeed, if it was easy, it would have been done long ago. But it's nonetheless > absolutely necessary. Q6String will not fit into a QList anymore. QVariant and > QModelIndex already don't. And given the extensive use of QVariant in QML/Qt's > property system, I don't think anyone can be happy about the per-element > memory allocation in QVariantList. Ok. I think the first thing we need is the QList replacement, whatever it is. I think the poisoning ideas can follow that, if at all. From ville.voutilainen at gmail.com Sat Mar 18 20:15:04 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Sat, 18 Mar 2017 21:15:04 +0200 Subject: [Development] QList In-Reply-To: References: <201703181837.16139.marc.mutz@kdab.com> <7341375.cH6AiziBB6@tjmaciei-mobl1> Message-ID: Sigh, I failed to reply to the list... On 18 March 2017 at 21:08, Ville Voutilainen wrote: > On 18 March 2017 at 20:15, Thiago Macieira wrote: >> During Qt 5 development, I began the process of rewriting QList so it suffered >> less from the problems it suffers, but I ran out of time and it was also an >> impossible task given the requirement to support C++98 at the time (no >> ). The objective was to make QList a hybrid: a real vector with >> no overhead for types smaller than 32 bytes, a pointer list otherwise. >> >> But as time went by, I don't think that hybrid approach is valid. A vector is >> simply much better. For Qt 6, I'd like QVector and QList to be the same type >> -- possibly even interchangeable, so that code that began using QVector in >> Qt 5 will be able to "return" QList. > > Sounds like a plan worth taking a stab at. > >>> > In other words, introduce generic code where there wasn't generic code >>> > before - users writing >>> > non-generic code calling non-templates that return QLists will need to >>> > use deduction or a metaprogramming tool. >>> >>> No, that is false. You can keep using QList for now everywhere you used it >>> so far, in non-generic code. Nothing changes for existing types. And for >>> new types, the compiler will make sure that you don't get away with QList. >>> We do recommened to use auto to receive QLists to avoid having to port >>> these code lines manually come Qt 6. I do not consider auto variables >>> "generic code". >> >> I don't agree with the poisoning. See my comment in the QStringView review. I > > Nor do I, but if we ever want to do such poisoning, we should poison > every use of a type, > including initialization and assignment. We can't realistically > prevent template instantiations, > because even C++17 can't do that; Concepts can but those are further > in the future. From apoenitz at t-online.de Sat Mar 18 20:16:15 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sat, 18 Mar 2017 20:16:15 +0100 Subject: [Development] QList In-Reply-To: <20170318184230.96AC.6F0322A@gmail.com> References: <20170318125420.GB5907@klara.mpi.htwm.de> <20170318184230.96AC.6F0322A@gmail.com> Message-ID: <20170318191615.GB7931@klara.mpi.htwm.de> On Sat, Mar 18, 2017 at 06:42:31PM +0100, Philippe wrote: > André Pönitz wrote: > > > Qt was prioritizing application developer convenience over raw performance, > > making it easier for an application developers to create something working > > in reasonable time. That included features like consistency in the API > > and naming in general that made it possible to transfer knowledge of one > > part of the API to another. This also included recommendations for "one > > size fits all" usage patterns including default choices for containers. > > Why are you speaking "in the past"?... > Is there a consensus that raw performance should now prime over developer > convenience? No. General consensus is still that performance improvements are good to have as long as convenience is not affected. But as there is no measure or even autotest for convenience, some people sometimes overstep, i.e. break existing uses, either unintentionally, simply because they are not aware of usage pattern, or even intentionally, because they do no consider that use case important, or "convenient". I am using past tense because the opinions on what "convenience" and "consistency" means are more diverse nowadays. Andre' From ville.voutilainen at gmail.com Sat Mar 18 20:15:59 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Sat, 18 Mar 2017 21:15:59 +0200 Subject: [Development] QList In-Reply-To: References: <201703181051.07307.marc.mutz@kdab.com> <4152187.FA5rFeLXhG@tjmaciei-mobl1> Message-ID: On 18 March 2017 at 21:04, Kevin Kofler wrote: > Thiago Macieira wrote: >> A lot. I don't think we can have Qt 6 without a class called "QList". But >> we can make it be the same as QVector, which is what we want people to >> use. > > So the user code will at least compile (unlike with Marc Mutz's approach), > but algorithms that previously completed in O(n) will now complete only in > O(mn) (and of course this multiplies on: if you were inserting into a QList > in a loop, it goes from O(n²) to O(mn²)), which is kinda ironic for a change > designed to "improve performance". It might be worth keeping this in mind: https://isocpp.org/blog/2014/06/stroustrup-lists From apoenitz at t-online.de Sat Mar 18 20:42:00 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sat, 18 Mar 2017 20:42:00 +0100 Subject: [Development] QList In-Reply-To: References: <201703181051.07307.marc.mutz@kdab.com> <4152187.FA5rFeLXhG@tjmaciei-mobl1> Message-ID: <20170318194200.GC7931@klara.mpi.htwm.de> On Sat, Mar 18, 2017 at 08:04:46PM +0100, Kevin Kofler wrote: > Thiago Macieira wrote: > > A lot. I don't think we can have Qt 6 without a class called "QList". But > > we can make it be the same as QVector, which is what we want people to > > use. > > So the user code will at least compile (unlike with Marc Mutz's approach), That would be pretty much my minimum requirement, i.e. to have *something* that is called 'QList', has most of QList's current interface, and at least (amortized) O(1) append and at() guarantees. > but algorithms that previously completed in O(n) will now complete only in > O(mn) (and of course this multiplies on: if you were inserting into a QList > in a loop, it goes from O(n²) to O(mn²)), which is kinda ironic for a change > designed to "improve performance". To be fair, Marc wants to kill QList, not replace it with something that has worse complexity in some cases. The irony here is due to people like you and I who insist on keeping their code compilable. Anyway, there could be a warning when using parts from Qt6's QList interface that have a worse complexity than Qt5's list. Andre' From thiago.macieira at intel.com Sat Mar 18 22:20:49 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 18 Mar 2017 14:20:49 -0700 Subject: [Development] Wishes for C++ standard or compilers Message-ID: <14194925.OZWiO3H5W7@tjmaciei-mobl1> Ville asked what would be nice to have, so I put together a list: == SD-6 feature macros == We made a decision not to add Q_COMPILER_xxx macros in Qt past C++11, and only depend on the ones from the standard. But there are several problems there: * some compilers don't have them at all (MSVC). Our current answer is "if you don't #define them, they don't exist" and therefore for us, MSVC has zero C++14 features. * some macros exist but are insufficient, as there are often bugs in implementations. You can see in qcompilerdetection.h where we've noted a feature being available in a compiler version further than where the compiler vendor said it is available (like GCC initializer_list, MSVC constexpr). If we use only what the compiler vendor claims, we may run into bugs. * some features are only marked by __has_include, which sometimes isn't sufficient as the header is present by fails to compile. == QString, QStringView, QByteArray == I've been thinking for the past 5 years what QString would look like then and how to avoid emitting atomic detaching code all over the place while not abandoning implicit sharing. I have some unfinished ideas I can share at a later time (glimpse given in the other thread). There's a question of whether QString should change encoding. I feel that it's simply not possible to change this, ever. In terms of what we'd need from the standard for UTF-16? Not much. Quite frankly, if the standard library sucks when it comes to Unicode, it's to Qt's benefit. As a former colleague of ours said some 10 years ago when we found QString symbols inside an application from a major OS vendor, "world domination starts with QString". == Containers == And then there's what to do with the containers. Here's where Marc's opinion and mine differ considerably. Aside from the need to maintain source compatibility, I feel like we should keep our containers and keep implicit sharing (same solution as for QString). We know COW can be a pessimisation for performance-sentive code, but the question is whether it is so for regular developers who don't know how to write performance-sensitive code. If developers will make mistakes, can we reduce the impact? == Misc == Off the top of my head, here are some things. Not all of these will be standards things, but might be compiler-specific. * better support for the Qt way of atomic implicitly-sharing. Specifically, that when the refcount is 1, the refcount stays at 1 unless the function in question increments it or calls a non-const function. Maybe this is about pre- and post-conditions? See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html * really const: The following reloads the s.i: struct S { int i; void f() const; }; void f(const S &); int f() { S s = { 0 }; f(s); return s.i; } https://godbolt.org/g/qaR9KU Or, identically: int f() { S s = { 0 }; s.f(); return s.i; } This has a lot of impacts in the QString, QByteArray and the containers, since they have out-of-line functions. So, can we have a way to do "really const"? Is that [[pure]] ? * not quite [[pure]] functions That's again the same thing as above: so long as a non-const function wasn't called, the result of many const member functions is supposed to remain the same. But these functions do read from memory. Example: int i = s.indexOf('/'); int j = s.indexOf('/'); i and j are guaranteed to be the same in our API, so long as the user did not violate our thread-safety conditions by writing to s from another thread. * the case of qGlobalQHashSeed(): it always returns the same thing, but on the first call it may make I/O to get random data. So this function can't be [[pure]]... * constexpr: as I said in std-proposals, I have asked Marc to sacrifice the constexprness of the QStringView's constructor taking a QChar* without length. This is not the only function in which we've had to do so; see qalgorithms.h for more. [changing gears] * QVariant: need to investigate std::any and what std::any can benefit from the Qt 5 improvements (Q{Sequential,Associative}Iterable, QObject covariance, etc.) * QVariant & metatype id: (if not using std::any) we need a constant identifier for each type and we need the type's name. The constant identifier for us is an int, but we could probably use the typeinfo. The difficult part is actually getting the type's name, since std::typeinfo does not guarantee that it will readable. Even for the compilers we support, it's not easy to extract the type name. This may come from reflection. * reflection: 'nuff said. * PMFs: we're running into UBs when we try to use PMFs as identifiers for signals. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Sat Mar 18 22:33:32 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 18 Mar 2017 22:33:32 +0100 Subject: [Development] QList In-Reply-To: <3812547.VS9TNzUDzq@tjmaciei-mobl1> References: <20170318125420.GB5907@klara.mpi.htwm.de> <3812547.VS9TNzUDzq@tjmaciei-mobl1> Message-ID: <201703182233.32675.marc.mutz@kdab.com> On Saturday 18 March 2017 19:30:35 Thiago Macieira wrote: > class QStringView - has all the const functions > class QString : public QStringView - adds the mutating functions > class QtExclusive::QString : public QString No inheritance. These things have no is-a relationship whatsoever. Example: QString cannot inherit QStringView because QStringView::trimmed() returns a QStringView while QString::trimmed() needs to return a QString. These return values aren't covariant, either, because a) they're not pointers, so C++ doesn't let you, b) the functions aren't virtual so C++ won't let you and c) the QStringView implementation has no idea how to manage QString's memory. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Sat Mar 18 22:51:08 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 18 Mar 2017 22:51:08 +0100 Subject: [Development] QList In-Reply-To: <4152187.FA5rFeLXhG@tjmaciei-mobl1> References: <4152187.FA5rFeLXhG@tjmaciei-mobl1> Message-ID: <201703182251.09481.marc.mutz@kdab.com> On Saturday 18 March 2017 19:05:44 Thiago Macieira wrote: > Em sábado, 18 de março de 2017, às 03:25:12 PDT, Ville Voutilainen escreveu: > > >> 2) What do we plan to do about those problems? > > > > > > Kill QList in Qt 6. > > > > How much valid code will that break? How many bugs does that avoid? > > A lot. I don't think we can have Qt 6 without a class called "QList". But > we can make it be the same as QVector, which is what we want people to > use. We can provide QArrayList as a replacement for anyone who needs > pointer stability if they can't use QSet or QHash. We dug us a very deep pit here. If you compare QPair's implementation with a typical std::pair's, you'll see that it's just totally pointless to keep classes alive that have 1:1 std equivalents. We'll just never get to the QOI of the std classes. Our time would be better spent fixing bugs in std implementations. One reason I'm against keeping "QList" as a fully supported Qt container name is the unfortunate impedance mismatch (all Qt's fault) with std::list. I don't want Qt to continue to poison people's minds with that mixup. Just use QVector. Make QList a type-alias for QVector, but deprecate it. And use QVector in the API and the docs (or std::vector). Our containers _still_ don't support move semantics correctly. Maybe Ville was hired to change that. If so, I'm sorry to say: what a waste of talent. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Sat Mar 18 23:13:34 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 18 Mar 2017 23:13:34 +0100 Subject: [Development] QList In-Reply-To: References: <201703181837.16139.marc.mutz@kdab.com> Message-ID: <201703182313.34883.marc.mutz@kdab.com> On Saturday 18 March 2017 20:05:59 Ville Voutilainen wrote: > On 18 March 2017 at 19:37, Marc Mutz wrote: > > > No, that is false. You can keep using QList for now everywhere you used > > it so far, in non-generic code. Nothing changes for existing types. And > > for new types, the compiler will make sure that you don't get away with > > QList. We do recommened to use auto to receive QLists to avoid having to > > port these code lines manually come Qt 6. I do not consider auto > > variables "generic code". > > Right. I, however, do consider them generic code. :) You're free to call a chicken a pig for your own entertainment, but in the interest of understanding what everyone says, please stick to established definitions. Generic code is generally understood to be code that uses generic programming, which in turn is defined as [...] an approach to software decomposition whereby fundamental requirements on types are abstracted from across concrete examples of algorithms and data structures and formalised as concepts, analogously to the abstraction of algebraic theories in abstract algebra. (Wikipedia, citing Stepanov/Musser). So neither auto i = int{0}; nor QHash hash = ...; auto values = hash.values(); are examples of generic code. > Ok. I think the first thing we need is the QList replacement, whatever > it is. I think the poisoning > ideas can follow that, if at all. That, at least, is simple: QVector is currectly the only viable choice. What to do with QVector in Qt 6 is in open debate. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From ville.voutilainen at gmail.com Sat Mar 18 23:12:31 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Sun, 19 Mar 2017 00:12:31 +0200 Subject: [Development] QList In-Reply-To: <201703182251.09481.marc.mutz@kdab.com> References: <4152187.FA5rFeLXhG@tjmaciei-mobl1> <201703182251.09481.marc.mutz@kdab.com> Message-ID: On 18 March 2017 at 23:51, Marc Mutz wrote: > We dug us a very deep pit here. If you compare QPair's implementation with a > typical std::pair's, you'll see that it's just totally pointless to keep > classes alive that have 1:1 std equivalents. We'll just never get to the QOI > of the std classes. Our time would be better spent fixing bugs in std > implementations. Well, having written the conditionally explicit constructors for pair, tuple and optional in libstdc++, I can certainly recommend against trying to duplicate that work. :) > Our containers _still_ don't support move semantics correctly. Maybe Ville was > hired to change that. If so, I'm sorry to say: what a waste of talent. Oh, not to worry, there's plenty of stuff I can be doing, container move semantics were probably hardly the only thing I was envisioned to work on. From ville.voutilainen at gmail.com Sat Mar 18 23:17:54 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Sun, 19 Mar 2017 00:17:54 +0200 Subject: [Development] QList In-Reply-To: <201703182313.34883.marc.mutz@kdab.com> References: <201703181837.16139.marc.mutz@kdab.com> <201703182313.34883.marc.mutz@kdab.com> Message-ID: On 19 March 2017 at 00:13, Marc Mutz wrote: >> > port these code lines manually come Qt 6. I do not consider auto >> > variables "generic code". >> Right. I, however, do consider them generic code. :) > You're free to call a chicken a pig for your own entertainment, but in the > interest of understanding what everyone says, please stick to established > definitions. Generic code is generally understood to be code that uses generic I have no trouble finding Concepts designers who consider auto the most generic concept, one that has no requirements. It fits right into a spectrum of constraints between a concrete type and, well, itself, as auto is the other end of that spectrum; that's especially true of auto-type parameters, which are already in C++14, but also of auto-type variables, which are already in C++11. Considering that you can use an auto-type variable as a result of an overloaded call, I daresay it fulfills the definition of generic code even by the measures you cited. From marc.mutz at kdab.com Sat Mar 18 23:32:55 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 18 Mar 2017 23:32:55 +0100 Subject: [Development] QList In-Reply-To: <3812547.VS9TNzUDzq@tjmaciei-mobl1> References: <20170318125420.GB5907@klara.mpi.htwm.de> <3812547.VS9TNzUDzq@tjmaciei-mobl1> Message-ID: <201703182332.55945.marc.mutz@kdab.com> On Saturday 18 March 2017 19:30:35 Thiago Macieira wrote: > QVector someFunction() // out-of-line > { > QtExclusive::QVector vector; > [ operate and populate vector ] > return vector; // automatic move > } > > in user code: > QtExclusive::QVector vector = someFunction(); // > automatic move [ mutate some more ] Breaks (N)RVO. And since the code outside has no clue about whether the code inside the function creates a shared or unshared QVector, the compiler will again have to emit the whole QVector copy constructor/detach code (as dead code) at the call site. You promised this would be gone in Qt 6 because of the removal of the unsharable state. > Why not std::vector? Because of the ability to put it back into shared mode, std::shared_ptr Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From kevin.kofler at chello.at Sun Mar 19 00:59:46 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 19 Mar 2017 00:59:46 +0100 Subject: [Development] QList References: <4152187.FA5rFeLXhG@tjmaciei-mobl1> <201703182251.09481.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > One reason I'm against keeping "QList" as a fully supported Qt container > name is the unfortunate impedance mismatch (all Qt's fault) with > std::list. I don't want Qt to continue to poison people's minds with that > mixup. Both the STL and Qt are equally at fault for using a terse, incompletely specified name there. The STL type should be called linked_list (just like the Qt and Java equivalents). The Qt QList could probably have received a better name too, especially considering the STL list was there first (though there is at least a logic behind calling the "default" list type just "list"). It is unfortunate that the STL consistently uses terse misleading names (e.g. "empty"), and even abbreviations such as "deque". > Our containers _still_ don't support move semantics correctly. Move semantics are almost useless in a world of implicitly shared containers. You save the reference counting and that's all. Kevin Kofler From marc.mutz at kdab.com Sun Mar 19 02:09:17 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sun, 19 Mar 2017 02:09:17 +0100 Subject: [Development] QList In-Reply-To: References: <201703182313.34883.marc.mutz@kdab.com> Message-ID: <201703190209.18344.marc.mutz@kdab.com> On Saturday 18 March 2017 23:17:54 Ville Voutilainen wrote: > On 19 March 2017 at 00:13, Marc Mutz wrote: > >> > port these code lines manually come Qt 6. I do not consider auto > >> > variables "generic code". > >> > >> Right. I, however, do consider them generic code. :) > > > > You're free to call a chicken a pig for your own entertainment, but in > > the interest of understanding what everyone says, please stick to > > established definitions. Generic code is generally understood to be code > > that uses generic > > I have no trouble finding Concepts designers who consider auto the most > generic concept, one that has no requirements. It fits right into a > spectrum of constraints > between a concrete type and, well, itself, as auto is the other end of > that spectrum; > that's especially true of auto-type parameters, which are already in C++14, > but also of auto-type variables, which are already in C++11. Considering > that you can use an auto-type variable as a result of an overloaded call, > I daresay it fulfills the definition of generic code even by the measures > you cited. Yes, auto can be called the most generic concept. Yes, using auto arguments makes a function generic. No, using auto to simply save having to write the type of the initialising expression in code that cannot be called generic in its original form does _not_ make said code generic. And that is what we were talking about: On Saturday 18 March 2017 11:25:12 Ville Voutilainen wrote: > On 18 March 2017 at 11:51, Marc Mutz wrote: > > 1. Replace QList in generic code by QListOrVector, tell users to hold > > QLists > > > > they get from Qt API only in type-deduced variables. > > In other words, introduce generic code where there wasn't generic code > before - users writing > non-generic code calling non-templates that return QLists will need to > use deduction or a metaprogramming tool. Ok, I can see where there might be a misunderstanding here. The comma in my original sentence should be read as a semicolon. I meant: 1a. Replace QList in generic code by QListOrVector 1b. Tell users to hold QLists they get from Qt API only in type-deduced variables. With (1b), I was referring to stuff like: QStringList parts = string.split(...); // Don't do that in new code auto parts = string.split(...); // do this instead -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From kuba at mareimbrium.org Sun Mar 19 03:33:19 2017 From: kuba at mareimbrium.org (Kuba Ober) Date: Sat, 18 Mar 2017 22:33:19 -0400 Subject: [Development] syncqt.pl in C++ In-Reply-To: <1733911.qi4zXjP78C@tjmaciei-mobl1> References: <1733911.qi4zXjP78C@tjmaciei-mobl1> Message-ID: <2591819D-E471-4520-ACF8-3E47D9D496A6@mareimbrium.org> > 7 mars 2017 kl. 15:54 skrev Thiago Macieira : > > Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard Moore escreveu: >>> The Qt Company has now very recently made a decision to now go and invest >>> the man power required to turn qbs into a product we can fully support in >>> the future. This decision comes from the fact that we see that build >>> systems are a very integral part of the developer experience, and it's one >>> of the areas where we see that there still is a large potential for >>> improvement. qbs is promising to bring that improvement to us and our >>> users. >> ​Pretty depressing since the discussions at the developer summit seemed to >> conclude the exact opposite.​ I wish those developers were working on >> something more useful than a new wheel. > > Same here, though I have also to concede that breaking the status quo (to > quote Jake's tweet) is sometimes a good idea. Teambuilder -- to name another > Trolltech project that had nothing to do with qt -- was a couple of orders of > magnitude better than the tools that existed at the time (distcc). Icecream/ > icecc came about only because TB wasn't open source, but every now and then I > miss TB2 features that icecc doesn't have. TB3 would have been even better. > > Maybe qbs will be another such leapfrog. I can't fault TQtC for trying. > > But as I said, I agree with Richard and I can't help but feel that the effort > could have been turned into making cmake even better, especially considering > everyone[*] (including Microsoft!) is using it. > > [*] for some reason, the other project I work with (IoTivity) chose Scons. > Ugh... cmake is a "build system" in the same sense as qmake is: it only generates output for the real build tool to deal with. Of this, in practice, ninja is the only tool that won't make you grow white hair waiting for it to finish. And even then, this presents an impedance mismatch between the abstract notion of a dependency as an arrow in a graph, and of the abstract nodes of this graph, and the concrete constraint of a file that make and ninja deal with organically. This leaves qbs and scons as the only contenders that let you use abstract dependencies and also the building themselves. I used scons a very long while ago and it was abysmally slow by design. I don't expect anything has changed there - not without a complete rearchitecting at least. So, as far as a build system that is fast and integrates a sane programming environment goes, qbs seems to be it. The other elephant in cmake's room is that the documentation provides nowhere nearly enough information to use it productively past trivial examples or to even develop for it well. I have to constantly refer to the source of various cmake modules to figure out how to use them beyond the simplest of ways and how to work around their shortcomings. Reading everything published about cmake, it seems like there is no single person who has a full knowledge of how this thing was meant to be implemented and used. Thus the preferred idioms evolve, diverge and merge all the time, and judging by the code of the modules there seems to be no consensus as to how to do almost anything. Reinventing the wheel runs rampant and ad-hoc solutions that are work arounds for design shortcomings are many. That this tool is considered to be the state of the art is lamentable at best. We all know it can and should be done better. That's my 2c from a user perspective. Cheers, Kuba From Jake.Petroules at qt.io Sun Mar 19 03:43:55 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Sun, 19 Mar 2017 02:43:55 +0000 Subject: [Development] syncqt.pl in C++ In-Reply-To: <2591819D-E471-4520-ACF8-3E47D9D496A6@mareimbrium.org> References: <1733911.qi4zXjP78C@tjmaciei-mobl1> <2591819D-E471-4520-ACF8-3E47D9D496A6@mareimbrium.org> Message-ID: <944A1FD4-DDD5-4FAB-BE38-0D99B5E59D7B@qt.io> > On Mar 18, 2017, at 7:33 PM, Kuba Ober wrote: > > cmake is a "build system" in the same sense as qmake is: it only generates output for the real build tool to deal with. Of this, in practice, ninja is the only tool that won't make you grow white hair waiting for it to finish. And even then, this presents an impedance mismatch between the abstract notion of a dependency as an arrow in a graph, and of the abstract nodes of this graph, and the concrete constraint of a file that make and ninja deal with organically. > > This leaves qbs and scons as the only contenders that let you use abstract dependencies and also the building themselves. I used scons a very long while ago and it was abysmally slow by design. I don't expect anything has changed there - not without a complete rearchitecting at least. So, as far as a build system that is fast and integrates a sane programming environment goes, qbs seems to be it. > > The other elephant in cmake's room is that the documentation provides nowhere nearly enough information to use it productively past trivial examples or to even develop for it well. I have to constantly refer to the source of various cmake modules to figure out how to use them beyond the simplest of ways and how to work around their shortcomings. > > Reading everything published about cmake, it seems like there is no single person who has a full knowledge of how this thing was meant to be implemented and used. Thus the preferred idioms evolve, diverge and merge all the time, and judging by the code of the modules there seems to be no consensus as to how to do almost anything. Reinventing the wheel runs rampant and ad-hoc solutions that are work arounds for design shortcomings are many. That this tool is considered to be the state of the art is lamentable at best. We all know it can and should be done better. > > That's my 2c from a user perspective. About time we see a well thought out and realistic posting on this subject. Thank you for your input. > > Cheers, Kuba > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From coroberti at gmail.com Sun Mar 19 09:39:57 2017 From: coroberti at gmail.com (Robert Iakobashvili) Date: Sun, 19 Mar 2017 10:39:57 +0200 Subject: [Development] Diff between Qt-5.7.1 and Qt-5.8.0 on Android - Pointer Below the Cursor at Text Fields Message-ID: Hi, Sorry for cross-posting, but maybe Qt Android maintainer is knowledgeable about the issue below. Nexus-7 with Android-6 The same Qt app built with 5.7.1 works properly and with 5.8.0 appears a blue pointer down the cursor at text fields (QTextEdit, QTextLine) The pointer is buggy and doesn't follow the cursor properly when positioning and re-positioning child-windows/popups. How to get rid from it? Were it some theme changes or something else from 5.7 to 5.8? Thanks Kind regards, Robert From olivier at woboq.com Sun Mar 19 10:24:56 2017 From: olivier at woboq.com (Olivier Goffart) Date: Sun, 19 Mar 2017 10:24:56 +0100 Subject: [Development] Wishes for C++ standard or compilers In-Reply-To: <14194925.OZWiO3H5W7@tjmaciei-mobl1> References: <14194925.OZWiO3H5W7@tjmaciei-mobl1> Message-ID: <3641713.vo5SbflUq4@maurice> On Samstag, 18. März 2017 22:20:49 CET Thiago Macieira wrote: > Ville asked what would be nice to have, so I put together a list: > > == SD-6 feature macros == > We made a decision not to add Q_COMPILER_xxx macros in Qt past C++11, and > only depend on the ones from the standard. But there are several problems > there: > > * some compilers don't have them at all (MSVC). Our current answer is "if > you don't #define them, they don't exist" and therefore for us, MSVC has > zero C++14 features. > > * some macros exist but are insufficient, as there are often bugs in > implementations. Well, bugs are bugs. That's not intentional. Sometimes they are known in advance, sometimes not. But the standard can't do anything about that. > You can see in qcompilerdetection.h where we've noted a > feature being available in a compiler version further than where the > compiler vendor said it is available (like GCC initializer_list, MSVC > constexpr). If we use only what the compiler vendor claims, we may run into > bugs. But don't think it's wise for a feature to be disabled entierly only because of a bug in a edge case. For example, on QNX, Q_COMPILER_UNICODE_STRINGS is disabled despite char16_t is there. And so one. > * some features are only marked by __has_include, which sometimes isn't > sufficient as the header is present by fails to compile. > > == QString, QStringView, QByteArray == > > I've been thinking for the past 5 years what QString would look like then > and how to avoid emitting atomic detaching code all over the place while > not abandoning implicit sharing. I have some unfinished ideas I can share > at a later time (glimpse given in the other thread). > > There's a question of whether QString should change encoding. I feel that > it's simply not possible to change this, ever. Yes, depending what level of compatibility Qt6 want to keep. > In terms of what we'd need from the standard for UTF-16? Not much. Quite > frankly, if the standard library sucks when it comes to Unicode, it's to > Qt's benefit. As a former colleague of ours said some 10 years ago when we > found QString symbols inside an application from a major OS vendor, "world > domination starts with QString". > > == Containers == > > And then there's what to do with the containers. Here's where Marc's opinion > and mine differ considerably. Aside from the need to maintain source > compatibility, I feel like we should keep our containers and keep implicit > sharing (same solution as for QString). We know COW can be a pessimisation > for performance-sentive code, but the question is whether it is so for > regular developers who don't know how to write performance-sensitive code. > If developers will make mistakes, can we reduce the impact? Yes, cow is quite convenient in some cases. > == Misc == > > Off the top of my head, here are some things. Not all of these will be > standards things, but might be compiler-specific. > > * better support for the Qt way of atomic implicitly-sharing. Specifically, > that when the refcount is 1, the refcount stays at 1 unless the function in > question increments it or calls a non-const function. > Maybe this is about pre- and post-conditions? See > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0542r0.html > > * really const: The following reloads the s.i: > struct S > { > int i; > void f() const; > }; > > void f(const S &); > int f() > { > S s = { 0 }; > f(s); > return s.i; > } > https://godbolt.org/g/qaR9KU > > Or, identically: > int f() > { > S s = { 0 }; > s.f(); > return s.i; > } > > This has a lot of impacts in the QString, QByteArray and the containers, > since they have out-of-line functions. So, can we have a way to do "really > const"? > > Is that [[pure]] ? > > * not quite [[pure]] functions > > That's again the same thing as above: so long as a non-const function wasn't > called, the result of many const member functions is supposed to remain the > same. But these functions do read from memory. Example: > > int i = s.indexOf('/'); > int j = s.indexOf('/'); > > i and j are guaranteed to be the same in our API, so long as the user did > not violate our thread-safety conditions by writing to s from another > thread. > > * the case of qGlobalQHashSeed(): it always returns the same thing, but on > the first call it may make I/O to get random data. So this function can't > be [[pure]]... > > * constexpr: as I said in std-proposals, I have asked Marc to sacrifice the > constexprness of the QStringView's constructor taking a QChar* without > length. This is not the only function in which we've had to do so; see > qalgorithms.h for more. > > [changing gears] > * QVariant: need to investigate std::any and what std::any can benefit from > the Qt 5 improvements (Q{Sequential,Associative}Iterable, QObject > covariance, etc.) The strength of QVariant compared to std::any is the connection with the QMetaType system. If you know the Qt meta type of any type T, you can know if it is a pointer type, if it inherits from QObject, and in this case you can get a pointer to the QMetaObject, you can know if it's an enum, you can know if it can be converted to any other type ad you can even register converter. > * QVariant & metatype id: (if not using std::any) we need a constant > identifier for each type and we need the type's name. The constant > identifier for us is an int, but we could probably use the typeinfo. The > difficult part is actually getting the type's name, since std::typeinfo > does not guarantee that it will readable. Even for the compilers we > support, it's not easy to extract the type name. This may come from > reflection. The thing is, we don't always need the name. We need the name to be registered for QueuedConnection of signals and slot connected with the string syntax. Appart from that, most useful features of the meta type system don't need the name. But because QMetaType was historically made for QueuedConnection, it needs the name, and so needs to be declared or registered with Q_DECLARE_METATYPE/ qRegisterMetaType. But the truth is that we could get rid of both already with what C++98. moc could generate the code that register the name for the signal arguments (it already does for some type, but that could be extended to all types). QMetaTypeid::name() would not work for every type but that's not so important. > * reflection: 'nuff said. > > * PMFs: we're running into UBs when we try to use PMFs as identifiers for > signals. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From thiago.macieira at intel.com Sun Mar 19 19:44:44 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 19 Mar 2017 11:44:44 -0700 Subject: [Development] QList In-Reply-To: <201703182233.32675.marc.mutz@kdab.com> References: <3812547.VS9TNzUDzq@tjmaciei-mobl1> <201703182233.32675.marc.mutz@kdab.com> Message-ID: <4326289.GUNhFrUgHh@tjmaciei-mobl1> On sábado, 18 de março de 2017 14:33:32 PDT Marc Mutz wrote: > On Saturday 18 March 2017 19:30:35 Thiago Macieira wrote: > > class QStringView - has all the const functions > > class QString : public QStringView - adds the mutating functions > > class QtExclusive::QString : public QString > > No inheritance. These things have no is-a relationship whatsoever. Right, I came to the same conclusion in the shower after posting this and then forgot to post once I was out. > Example: QString cannot inherit QStringView because QStringView::trimmed() > returns a QStringView while QString::trimmed() needs to return a QString. I don't see why you need to. If you called the object as QStringView, then you get QStringView too. My problem was the exclusive kind, because you could then do: QtExclusive::QString es; QString &s = es; s = somethingElse(); // es could now be sharing, which is a violation > These return values aren't covariant, either, because a) they're not > pointers, so C++ doesn't let you, b) the functions aren't virtual so C++ > won't let you and c) the QStringView implementation has no idea how to > manage QString's memory. Covariants are only needed if they were virtual. They're not, they can be just pure overrides. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Mar 19 19:48:36 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 19 Mar 2017 11:48:36 -0700 Subject: [Development] QList In-Reply-To: <201703182332.55945.marc.mutz@kdab.com> References: <3812547.VS9TNzUDzq@tjmaciei-mobl1> <201703182332.55945.marc.mutz@kdab.com> Message-ID: <3222957.Av71qoJJfk@tjmaciei-mobl1> On sábado, 18 de março de 2017 15:32:55 PDT Marc Mutz wrote: > On Saturday 18 March 2017 19:30:35 Thiago Macieira wrote: > > QVector someFunction() // out-of-line > > { > > > > QtExclusive::QVector vector; > > [ operate and populate vector ] > > return vector; // automatic move > > > > } > > > > in user code: > > QtExclusive::QVector vector = someFunction(); // > > > > automatic move [ mutate some more ] > > Breaks (N)RVO. How? > And since the code outside has no clue about whether the code inside the > function creates a shared or unshared QVector, the compiler will again have > to emit the whole QVector copy constructor/detach code (as dead code) at > the call site. You promised this would be gone in Qt 6 because of the > removal of the unsharable state. QtExclusive::QVector's move constructor for QVector always needs to emit copying code, since it doesn't know whether the data is shared or not. There's no way around that. QVector's move constructor for QtExclusive::QVector simply adopts the data and starts reference-counting. You could argue that a function that always returns an unshared vector could return QtExclusive::QVector. But we should not allow that in our API any more that we allow returning references. > > Why not std::vector? Because of the ability to put it back into shared > > mode, > std::shared_ptr One level of indirection too many. We've been over this. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Mar 19 19:51:47 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 19 Mar 2017 11:51:47 -0700 Subject: [Development] Wishes for C++ standard or compilers In-Reply-To: <3641713.vo5SbflUq4@maurice> References: <14194925.OZWiO3H5W7@tjmaciei-mobl1> <3641713.vo5SbflUq4@maurice> Message-ID: <1862892.9S7BqHnF9X@tjmaciei-mobl1> On domingo, 19 de março de 2017 02:24:56 PDT Olivier Goffart wrote: > But because QMetaType was historically made for QueuedConnection, it needs > the name, and so needs to be declared or registered with > Q_DECLARE_METATYPE/ qRegisterMetaType. But the truth is that we could get > rid of both already with what C++98. moc could generate the code that > register the name for the signal arguments (it already does for some type, > but that could be extended to all types). QMetaTypeid::name() would not > work for every type but that's not so important. The name is necessary for compatiblity iwth other languages. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Mar 19 20:01:29 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 19 Mar 2017 12:01:29 -0700 Subject: [Development] Who's responsible for 3rdparty these days (QTBUG-59586)? Message-ID: <1923287.X8lTtAKxnU@tjmaciei-mobl1> The rules are that only Qt Company people can import 3rdparty code, so I know I am not responsible. Who do I assign the bug to? https://bugreports.qt.io/browse/QTBUG-59586 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From olivier at woboq.com Mon Mar 20 08:20:33 2017 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 20 Mar 2017 08:20:33 +0100 Subject: [Development] Wishes for C++ standard or compilers In-Reply-To: <1862892.9S7BqHnF9X@tjmaciei-mobl1> References: <14194925.OZWiO3H5W7@tjmaciei-mobl1> <3641713.vo5SbflUq4@maurice> <1862892.9S7BqHnF9X@tjmaciei-mobl1> Message-ID: <15872998.a0DfYGXGuC@maurice> On Sonntag, 19. März 2017 19:51:47 CET Thiago Macieira wrote: > On domingo, 19 de março de 2017 02:24:56 PDT Olivier Goffart wrote: > > But because QMetaType was historically made for QueuedConnection, it needs > > the name, and so needs to be declared or registered with > > Q_DECLARE_METATYPE/ qRegisterMetaType. But the truth is that we could get > > rid of both already with what C++98. moc could generate the code that > > register the name for the signal arguments (it already does for some type, > > but that could be extended to all types). QMetaTypeid::name() would not > > work for every type but that's not so important. > > The name is necessary for compatiblity iwth other languages. Can you elaborate? In QtScript or QtQml, the name is only used for error message, or for compatibility before the QMetaObject was in the QMetaType. Types that can be used directly needs to be registered with functions such as qmlRegisterMetaType I see many use in QtDBus but I suppose if it falls in the category of types used for signals and slot which could be registered by moc. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From marc.mutz at kdab.com Mon Mar 20 09:09:57 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 20 Mar 2017 09:09:57 +0100 Subject: [Development] QList In-Reply-To: <3222957.Av71qoJJfk@tjmaciei-mobl1> References: <201703182332.55945.marc.mutz@kdab.com> <3222957.Av71qoJJfk@tjmaciei-mobl1> Message-ID: <201703200909.58409.marc.mutz@kdab.com> On Sunday 19 March 2017 19:48:36 Thiago Macieira wrote: > On sábado, 18 de março de 2017 15:32:55 PDT Marc Mutz wrote: > > On Saturday 18 March 2017 19:30:35 Thiago Macieira wrote: > > > QVector someFunction() // out-of-line > > > { > > > > > > QtExclusive::QVector vector; > > > [ operate and populate vector ] > > > return vector; // automatic move > > > > > > } > > > > > > in user code: > > > QtExclusive::QVector vector = someFunction(); // > > > > > > automatic move [ mutate some more ] > > > > Breaks (N)RVO. > > How? Returned Type != (Declared) Return Type != Expected Type (by caller) For NRVO, all three must be identical, for RVO the last two. > > And since the code outside has no clue about whether the code inside the > > function creates a shared or unshared QVector, the compiler will again > > have to emit the whole QVector copy constructor/detach code (as dead > > code) at the call site. You promised this would be gone in Qt 6 because > > of the removal of the unsharable state. > > QtExclusive::QVector's move constructor for QVector always needs to emit > copying code, since it doesn't know whether the data is shared or not. > There's no way around that. > > QVector's move constructor for QtExclusive::QVector simply adopts the data > and starts reference-counting. Sure, I understand that. It's the misuse of QVector when exclusive QVector was needed that is the problem: > You could argue that a function that always returns an unshared vector > could return QtExclusive::QVector. Exactly that. > But we should not allow that in our API > any more that we allow returning references. Yes, that was my fear. The exclusive split sounded like a good idea, like unique_ptr vs. shared_ptr, one that could actually win me over to support keeping any form of Qt container at all, long-term. Until right now. If you would propose to make QVector exclusive, maybe with SOO, and provide QSharedVector, but to default to QVector in API, you would probably have me on board. It's a fallacy to think that there's a lot of need to return a shared collection from APIs. Either you create the collection on request, then an exclusive collection would be preferable, as returning it from a function is free[1], or you "return" internal state, in which case returning some form of view (incl. the case of simply adding begin()/end()) would be the way to go (cf. https://codereview.qt-project.org/150658). Even if your pov is that you should always return an owning collection in these cases, and that it therefore has to be a shared one, existing Qt code (QObject::children()) shows that even CoW is too slow in these cases (children() returns by const-&). If QObject was iterable as a container of QObject*, that would both be more convenient as well as faster). [1] yes, _is_. Ville may correct me if I'm wrong, but afaiu, C++17 makes (N)RVO mandatory. Sorry, GCC, you'll have to finally do something about your broken NRVO. > > > Why not std::vector? Because of the ability to put it back into shared > > > mode, > > > > std::shared_ptr > > One level of indirection too many. We've been over this. iow: you'd rather pay some large overhead every time than pay a larger one only in cases where it's needed. And this is where we fundamentally disagree. Even our API guidelines stipulate that you should make common things easy and not-so-common things possible. Sharing is _not_ common and it need not be as easy as common tasks. Iteration, builing a container from scratch, returning by NRVO from a function, these are common things. And CoW pessimises such common things - not only performance-wise, but also conceptually: std::vector doesn't need qAsConst when used with ranged for loops, std::vector doesn't invalidate iterators when copied from... Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From philwave at gmail.com Mon Mar 20 09:28:33 2017 From: philwave at gmail.com (Philippe) Date: Mon, 20 Mar 2017 09:28:33 +0100 Subject: [Development] QList In-Reply-To: <201703200909.58409.marc.mutz@kdab.com> References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703200909.58409.marc.mutz@kdab.com> Message-ID: <20170320092832.2712.6F0322A@gmail.com> >>Even our API guidelines stipulate that you should make common things easy and >>not-so-common things possible. Sharing is _not_ common and it need not be as >> easy as common tasks. I Maybe for you, but in my works, sharing _is_ common, convenient and safe. And overal usage of COW is one of the concept that makes Qt stand apart. From my POV, COW largely pay off its minimal performance cost. When performance is a high priority, _an uncommon case_, then using alternate containers is always possible and we don't need Qt for this. And when size matters, have this in mind: sizeof(std::vector) == 32 sizeof(QVector) == 8 sizeof(QList) == 8 (VC++ 64bit) Philippe On Mon, 20 Mar 2017 09:09:57 +0100 Marc Mutz wrote: > On Sunday 19 March 2017 19:48:36 Thiago Macieira wrote: > > On sábado, 18 de março de 2017 15:32:55 PDT Marc Mutz wrote: > > > On Saturday 18 March 2017 19:30:35 Thiago Macieira wrote: > > > > QVector someFunction() // out-of-line > > > > { > > > > > > > > QtExclusive::QVector vector; > > > > [ operate and populate vector ] > > > > return vector; // automatic move > > > > > > > > } > > > > > > > > in user code: > > > > QtExclusive::QVector vector = someFunction(); // > > > > > > > > automatic move [ mutate some more ] > > > > > > Breaks (N)RVO. > > > > How? > > Returned Type != (Declared) Return Type != Expected Type (by caller) > > For NRVO, all three must be identical, for RVO the last two. > > > > And since the code outside has no clue about whether the code inside the > > > function creates a shared or unshared QVector, the compiler will again > > > have to emit the whole QVector copy constructor/detach code (as dead > > > code) at the call site. You promised this would be gone in Qt 6 because > > > of the removal of the unsharable state. > > > > QtExclusive::QVector's move constructor for QVector always needs to emit > > copying code, since it doesn't know whether the data is shared or not. > > There's no way around that. > > > > QVector's move constructor for QtExclusive::QVector simply adopts the data > > and starts reference-counting. > > Sure, I understand that. It's the misuse of QVector when exclusive QVector was > needed that is the problem: > > > You could argue that a function that always returns an unshared vector > > could return QtExclusive::QVector. > > Exactly that. > > > But we should not allow that in our API > > any more that we allow returning references. > > Yes, that was my fear. > > The exclusive split sounded like a good idea, like unique_ptr vs. shared_ptr, > one that could actually win me over to support keeping any form of Qt > container at all, long-term. Until right now. > > If you would propose to make QVector exclusive, maybe with SOO, and provide > QSharedVector, but to default to QVector in API, you would probably have me on > board. > > It's a fallacy to think that there's a lot of need to return a shared > collection from APIs. Either you create the collection on request, then an > exclusive collection would be preferable, as returning it from a function is > free[1], or you "return" internal state, in which case returning some form of > view (incl. the case of simply adding begin()/end()) would be the way to go > (cf. https://codereview.qt-project.org/150658). > > Even if your pov is that you should always return an owning collection in > these cases, and that it therefore has to be a shared one, existing Qt code > (QObject::children()) shows that even CoW is too slow in these cases > (children() returns by const-&). If QObject was iterable as a container of > QObject*, that would both be more convenient as well as faster). > > [1] yes, _is_. Ville may correct me if I'm wrong, but afaiu, C++17 makes > (N)RVO mandatory. Sorry, GCC, you'll have to finally do something about your > broken NRVO. > > > > > Why not std::vector? Because of the ability to put it back into shared > > > > mode, > > > > > > std::shared_ptr > > > > One level of indirection too many. We've been over this. > > iow: you'd rather pay some large overhead every time than pay a larger one > only in cases where it's needed. And this is where we fundamentally disagree. > > Even our API guidelines stipulate that you should make common things easy and > not-so-common things possible. Sharing is _not_ common and it need not be as > easy as common tasks. Iteration, builing a container from scratch, returning > by NRVO from a function, these are common things. And CoW pessimises such > common things - not only performance-wise, but also conceptually: std::vector > doesn't need qAsConst when used with ranged for loops, std::vector doesn't > invalidate iterators when copied from... > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Mon Mar 20 09:40:53 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 20 Mar 2017 08:40:53 +0000 Subject: [Development] QList In-Reply-To: <7341375.cH6AiziBB6@tjmaciei-mobl1> References: <201703181837.16139.marc.mutz@kdab.com> <7341375.cH6AiziBB6@tjmaciei-mobl1> Message-ID: <5AA7048F-C952-40FA-9E6D-E53836D823E6@qt.io> > On 18 Mar 2017, at 19:15, Thiago Macieira wrote: > > Em sábado, 18 de março de 2017, às 10:37:15 PDT, Marc Mutz escreveu: >> Ville, >> >> A word of warning: when it comes to QList, there's a very vocal minority >> that claims that either QList works perfectly well or else ain't so bad. >> But afaict, there's consensus between the people who actually count (sorry >> to be blunt, but Qt is not a democracy, but a meritocracy) that QList as-is >> currently was a mistake and needs to go in Qt 6. The only difference in >> opinion is how to cushion the fall. >> >> Lars, Thiago: it would be nice if you could confirm (or deny, in case I >> misinterpreted) the above as soon as you can. Otherwise this thread will >> derail massively again. > > I think we're in agreement. Yes, we agree that QList as it is today is nothing we want in Qt 6. But we can’t simply remove it neither, as it would break way too much user code out there. > > During Qt 5 development, I began the process of rewriting QList so it suffered > less from the problems it suffers, but I ran out of time and it was also an > impossible task given the requirement to support C++98 at the time (no > ). The objective was to make QList a hybrid: a real vector with > no overhead for types smaller than 32 bytes, a pointer list otherwise. > > But as time went by, I don't think that hybrid approach is valid. A vector is > simply much better. For Qt 6, I'd like QVector and QList to be the same type > -- possibly even interchangeable, so that code that began using QVector in > Qt 5 will be able to "return" QList. +1 on this. They are pretty much API compatible, so this should be rather straightforward. This does cause a change in runtime behaviour for people storing very large objects in the container that we will need to document carefully. But it will IMO work very nicely for 95% of it’s uses, and even give some performance benefits in those cases. > >>> In other words, introduce generic code where there wasn't generic code >>> before - users writing >>> non-generic code calling non-templates that return QLists will need to >>> use deduction or a metaprogramming tool. >> >> No, that is false. You can keep using QList for now everywhere you used it >> so far, in non-generic code. Nothing changes for existing types. And for >> new types, the compiler will make sure that you don't get away with QList. >> We do recommened to use auto to receive QLists to avoid having to port >> these code lines manually come Qt 6. I do not consider auto variables >> "generic code". > > I don't agree with the poisoning. See my comment in the QStringView review. I > agree we should teach users to port away from QList, but not hat it's such a > terrible class that they have to port right now, before using new > functionality. Agree with Thiago. If we do turn QList into QVector, there is IMO no need to poison things right now. Simply replacing all our uses for Qt 6 and maybe deprecating QList then should be enough. > >>>> 4. Provide QArrayList for code that needs stability of references >>>> (stability >>>> >>>> statically checked in Qt 5, enforced in Qt 6). >>> >>> It seems that (4) is perfectly safe, whereas (2) and (3) are breaking >>> changes; to what extent, I would like to know. > > Actually, we can get started in (4) right now. This will allow porting now. That’s probably a good idea. It would help to have that class in 5.10 or latest 5.11. > >> (2) is possibly breaking, yes. We should intercept by deprecating >> QList::toSet() and re-adding it as a free function. > > Isn't that simply std::copy? > >> (3) is breaking nothing for existing code, since it only applies to new >> types. New types don't magically show up in your source code. You have to >> introduce them yourself. As for existing generic code, it's a >> source-incompatibility that is accepted, because it can be fixed by using >> auto variables. Or you don't use the new type at all. I mean, we're not >> talking about QString here. With very few exceptions, any type we're adding >> now will not get widespread use before Qt 6, anyway. One exception >> hopefully being QStringView. > > It's abou the message it brings. Doing that is telling people to port right > away, not when they have the time to do it properly. > >> Indeed, if it was easy, it would have been done long ago. But it's >> nonetheless absolutely necessary. Q6String will not fit into a QList >> anymore. QVariant and QModelIndex already don't. And given the extensive >> use of QVariant in QML/Qt's property system, I don't think anyone can be >> happy about the per-element memory allocation in QVariantList. > > Aye. Yep, we all agree on this :) Cheers, Lars From rjvbertin at gmail.com Mon Mar 20 09:57:00 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Mon, 20 Mar 2017 09:57 +0100 Subject: [Development] applications dropping keyboard input References: <2406425.BpbWke4HcW@bola> Message-ID: <17157635.RBlUImD6AP@patux.local> Hi, I forgot to mention something that provide another reason why I think the shell itself cannot be the part that drops input: copy/paste still works. That is, I can use whatever subterfuge I want to put a terminal command on the clipboard; if I paste it into a "deaf" terminal window or tab and the command has a newline append it will be executed by the shell running in that window or tab. The same was true for the deaf KDevelop window: input from the clipboard still appeared. Of course I had to use the Paste menu action in both cases. I did consider the possibility that something in the shell or the readline/libedit libraries it uses put a relevant component of the event handling loop in an unforeseen state, which also would explain why keyboard input doesn't even appear in the window (most of the time it does if the shell has simply "disconnected"). For a long time I thought that must be in Konsole. Except that I never found anything in its event handling code that seemed like it could explain my symptom. As you know I also have a functional XCB QPA plugin on my Mac and have actually been using Konsole 5 under X11 as my main terminal emulator for months now. Works really nicely. Of course that XCB QPA plugin is used with a Qt install otherwise built for Cocoa, and basically all KF5 software is built that way too so binaries lack all X11 specific code not provided by the QPA (or the KWindowSystem framework). R. From marc.mutz at kdab.com Mon Mar 20 10:08:18 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 20 Mar 2017 10:08:18 +0100 Subject: [Development] QList In-Reply-To: <20170320092832.2712.6F0322A@gmail.com> References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703200909.58409.marc.mutz@kdab.com> <20170320092832.2712.6F0322A@gmail.com> Message-ID: <201703201008.18789.marc.mutz@kdab.com> On Monday 20 March 2017 09:28:33 Philippe wrote: > And when size matters, have this in mind: > > sizeof(std::vector) == 32 > sizeof(QVector) == 8 > sizeof(QList) == 8 > > (VC++ 64bit) ROTFL. Thanks, you made my day. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Mon Mar 20 11:07:08 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 20 Mar 2017 11:07:08 +0100 Subject: [Development] QList In-Reply-To: <5AA7048F-C952-40FA-9E6D-E53836D823E6@qt.io> References: <7341375.cH6AiziBB6@tjmaciei-mobl1> <5AA7048F-C952-40FA-9E6D-E53836D823E6@qt.io> Message-ID: <201703201107.09339.marc.mutz@kdab.com> On Monday 20 March 2017 09:40:53 Lars Knoll wrote: > >>>> 4. Provide QArrayList for code that needs stability of references > >>>> (stability > >>>> > >>>> statically checked in Qt 5, enforced in Qt 6). > >>> > >>> It seems that (4) is perfectly safe, whereas (2) and (3) are breaking > >>> changes; to what extent, I would like to know. > > > > Actually, we can get started in (4) right now. This will allow porting > > now. > > That’s probably a good idea. It would help to have that class in 5.10 or > latest 5.11. https://codereview.qt-project.org/188938 I've made it a type-alias so we can rewrite code without breaking source or binary compatibility. It still checks that a QList so redeclared is actually one with an indirect memory layout. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From konrad at silmor.de Mon Mar 20 11:27:44 2017 From: konrad at silmor.de (Konrad Rosenbaum) Date: Mon, 20 Mar 2017 11:27:44 +0100 Subject: [Development] Wishes for C++ standard or compilers In-Reply-To: <15872998.a0DfYGXGuC@maurice> References: <14194925.OZWiO3H5W7@tjmaciei-mobl1> <3641713.vo5SbflUq4@maurice> <1862892.9S7BqHnF9X@tjmaciei-mobl1> <15872998.a0DfYGXGuC@maurice> Message-ID: Hi, On Mon, March 20, 2017 08:20, Olivier Goffart wrote: > On Sonntag, 19. März 2017 19:51:47 CET Thiago Macieira wrote: >> The name is necessary for compatiblity iwth other languages. > > Can you elaborate? > In QtScript or QtQml, the name is only used for error message, or for > compatibility before the QMetaObject was in the QMetaType. > Types that can be used directly needs to be registered with functions such > as > qmlRegisterMetaType > > I see many use in QtDBus but I suppose if it falls in the category of > types > used for signals and slot which could be registered by moc. There are more bindings than just QtScript and QML. Any dynamic binding that does not want to force the user to register again(!) every single type that could possibly appear somewhere in the API needs to know the name. At least if it wants to be compatible with itself between versions and platforms. Type IDs can change in between versions of a program or even if only an underlying library is updated. For example: I'm currently writing a utility that taps into a Qt program without modifying the program itself and allows to inspect objects and properties (something technically similar to GammaRay). In order to serialize and deserialize the properties of objects I need to be able to reliably determine the type of those properties on both sides and be able to reconstruct them, or at least to be able to determine whether I need to fall back to a string representation. For user types the name is much more reliable than the ID. In other projects I've used the MetaType system to expose type names of data stored in a QVariant to Tcl based scripts, a formula parser with dynamic typing, a template rendering system, or debugger utilities. The common theme among those was that I did not know what types my utility would face at the time I wrote the utility accessing QVariant. And those utilities usually work rather invisible to the libraries originating the types used in them and vice versa. In short: being able to get both an ID and a name for a type stored in QVariant makes a lot of magic possible that would otherwise require major blobs of glue code or it would otherwise simply be so inconvenient to use that it wouldn't be worth bothering. Konrad From Kai.Koehne at qt.io Mon Mar 20 11:47:44 2017 From: Kai.Koehne at qt.io (Kai Koehne) Date: Mon, 20 Mar 2017 10:47:44 +0000 Subject: [Development] Who's responsible for 3rdparty these days (QTBUG-59586)? In-Reply-To: <1923287.X8lTtAKxnU@tjmaciei-mobl1> References: <1923287.X8lTtAKxnU@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Thiago Macieira > Sent: Sunday, March 19, 2017 8:01 PM > To: development at qt-project.org > Subject: [Development] Who's responsible for 3rdparty these days (QTBUG- > 59586)? > > The rules are that only Qt Company people can import 3rdparty code, so I > know I am not responsible. I don't think this is the case. Every contributor can upload patches with new third party code, as long as this is properly documented. Only maintainers are allowed to approve them though, and if you want to add new third party code to the Qt libraries, tools or plugins you need an approval by Lars. Not formally approved yet, but QUIP-4 explicitly states the rules: https://codereview.qt-project.org/#/c/177201/ Regards Kai From olivier at woboq.com Mon Mar 20 12:02:45 2017 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 20 Mar 2017 12:02:45 +0100 Subject: [Development] Wishes for C++ standard or compilers In-Reply-To: References: <14194925.OZWiO3H5W7@tjmaciei-mobl1> <15872998.a0DfYGXGuC@maurice> Message-ID: <2443492.7KKUBh7ld7@maurice> On Montag, 20. März 2017 11:27:44 CET Konrad Rosenbaum wrote: > Hi, > > On Mon, March 20, 2017 08:20, Olivier Goffart wrote: > > On Sonntag, 19. März 2017 19:51:47 CET Thiago Macieira wrote: > >> The name is necessary for compatiblity iwth other languages. > > > > Can you elaborate? > > In QtScript or QtQml, the name is only used for error message, or for > > compatibility before the QMetaObject was in the QMetaType. > > Types that can be used directly needs to be registered with functions such > > as > > qmlRegisterMetaType > > > > I see many use in QtDBus but I suppose if it falls in the category of > > types > > used for signals and slot which could be registered by moc. > > There are more bindings than just QtScript and QML. > > Any dynamic binding that does not want to force the user to register > again(!) every single type that could possibly appear somewhere in the API > needs to know the name. At least if it wants to be compatible with itself > between versions and platforms. Type IDs can change in between versions of > a program or even if only an underlying library is updated. > > For example: I'm currently writing a utility that taps into a Qt program > without modifying the program itself and allows to inspect objects and > properties (something technically similar to GammaRay). In order to > serialize and deserialize the properties of objects I need to be able to > reliably determine the type of those properties on both sides and be able > to reconstruct them, or at least to be able to determine whether I need to > fall back to a string representation. For user types the name is much more > reliable than the ID. > > In other projects I've used the MetaType system to expose type names of > data stored in a QVariant to Tcl based scripts, a formula parser with > dynamic typing, a template rendering system, or debugger utilities. > > The common theme among those was that I did not know what types my utility > would face at the time I wrote the utility accessing QVariant. And those > utilities usually work rather invisible to the libraries originating the > types used in them and vice versa. > > In short: being able to get both an ID and a name for a type stored in > QVariant makes a lot of magic possible that would otherwise require major > blobs of glue code or it would otherwise simply be so inconvenient to use > that it wouldn't be worth bothering. Yes you are right, the name is still nice to have for serialization. For QObject properties, moc can (and already does for some types) register the type name. It's true that you cannot serialize a type if you don't have some persistent identifier such as the name. From bstottle at ford.com Mon Mar 20 12:25:56 2017 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Mon, 20 Mar 2017 11:25:56 +0000 Subject: [Development] Wishes for C++ standard or compilers In-Reply-To: <2443492.7KKUBh7ld7@maurice> References: <14194925.OZWiO3H5W7@tjmaciei-mobl1> <15872998.a0DfYGXGuC@maurice> <2443492.7KKUBh7ld7@maurice> Message-ID: On 3/20/17, 7:02 AM, "Development on behalf of Olivier Goffart" wrote: > > It's true that you cannot serialize a type if you don't have some persistent > identifier such as the name. This has probably been covered, but it may be worth mentioning. The examples Konrad used were in-process. Qt Remote Objects works between processes and between devices, so the id for registered (user) types becomes unreliable. The id is determined by the order the types are registered, so the name is needed by Qt Remote Objects too. Regards, Brett From robin.burchell at crimson.no Mon Mar 20 13:13:23 2017 From: robin.burchell at crimson.no (Robin Burchell) Date: Mon, 20 Mar 2017 13:13:23 +0100 Subject: [Development] QList In-Reply-To: <20170320092832.2712.6F0322A@gmail.com> References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703200909.58409.marc.mutz@kdab.com> <20170320092832.2712.6F0322A@gmail.com> Message-ID: <1490012003.2674178.917020488.488D5BF3@webmail.messagingengine.com> Hi Philippe, On Mon, Mar 20, 2017, at 09:28 AM, Philippe wrote: > >>Even our API guidelines stipulate that you should make common things easy and > >>not-so-common things possible. Sharing is _not_ common and it need not be as > >> easy as common tasks. I > > Maybe for you, but in my works, sharing _is_ common, convenient and safe. > And overal usage of COW is one of the concept that makes Qt stand apart. > From my POV, COW largely pay off its minimal performance cost. > When performance is a high priority, _an uncommon case_, then using > alternate containers is always possible and we don't need Qt for this. I don't know your background, but let's assume you are primarily a user of Qt (thus: an application developer of some kind), you may consider performance to be unimportant, or important only in isolated areas of your application. Consider, however, the point of view from many of the people on this list: as Qt uses itself in its own implementation, Qt must have acceptable performance for end user applications to be able to have acceptable performance at all - whether or not it is a priority to those developers. A few concrete examples of where data types matter a lot: signal connections (involves storing a bunch of data), QObject (particularly QObject::children, as already mentioned), event handling from the operating system (or the application itself: the event posting mechanism in QCoreApplication)... > And when size matters, have this in mind: > > sizeof(std::vector) == 32 > sizeof(QVector) == 8 > sizeof(QList) == 8 To provide a more helpful response than Marc's: I assume that you are aware that the Qt types just contain a pointer to a thing which contains the actual data (unlike std::vector), right? That is, QVector is actually (snipped from source): template class QVector { typedef QTypedArrayData Data; Data *d; } Where QTypedArrayData is a QArrayData, which is: struct Q_CORE_EXPORT QArrayData { QtPrivate::RefCount ref; int size; uint alloc : 31; uint capacityReserved : 1; qptrdiff offset; } If I'm adding it up right, this gives me a total cost of 32 bytes on my system. Although the real cost is actually higher I'd guess, due to the two being allocated in separate pieces (given that malloc usually has some kind of book-keeping overhead). Robin -- Robin Burchell robin at crimson.no From ville.voutilainen at gmail.com Mon Mar 20 13:37:41 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Mon, 20 Mar 2017 14:37:41 +0200 Subject: [Development] QList In-Reply-To: <1490012003.2674178.917020488.488D5BF3@webmail.messagingengine.com> References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703200909.58409.marc.mutz@kdab.com> <20170320092832.2712.6F0322A@gmail.com> <1490012003.2674178.917020488.488D5BF3@webmail.messagingengine.com> Message-ID: On 20 March 2017 at 14:13, Robin Burchell wrote: >> And when size matters, have this in mind: >> >> sizeof(std::vector) == 32 >> sizeof(QVector) == 8 >> sizeof(QList) == 8 > > To provide a more helpful response than Marc's: I assume that you are > aware that the Qt types just contain a pointer to a thing which contains > the actual data (unlike std::vector), right? libstdc++ vector is 24, it seems as if msvc's vector is just padded to an alignment boundary(*). I don't see anything particularly alarming in that size. (*) it might be remotely possible that it fails to remove storage for an empty allocator, but I kinda doubt that. > That is, QVector is actually (snipped from source): > template > class QVector > { > typedef QTypedArrayData Data; > Data *d; > } > > Where QTypedArrayData is a QArrayData, which is: > struct Q_CORE_EXPORT QArrayData > { > QtPrivate::RefCount ref; > int size; > uint alloc : 31; > uint capacityReserved : 1; > qptrdiff offset; > } > > If I'm adding it up right, this gives me a total cost of 32 bytes on my > system. Although the real cost is actually higher I'd guess, due to the > two being allocated in separate pieces (given that malloc usually has > some kind of book-keeping overhead). Yep. From Martin.Smith at qt.io Mon Mar 20 13:42:09 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 20 Mar 2017 12:42:09 +0000 Subject: [Development] QList In-Reply-To: <1490012003.2674178.917020488.488D5BF3@webmail.messagingengine.com> References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703200909.58409.marc.mutz@kdab.com> <20170320092832.2712.6F0322A@gmail.com>, <1490012003.2674178.917020488.488D5BF3@webmail.messagingengine.com> Message-ID: >Qt must have acceptable performance for end user applications to be able to have >acceptable performance at all - whether or not it is a priority to those developers. I write an application that has two performance requirements: 1. It must complete execution in 1 minute. 2. It must not run out of memory. If I use QList in my application instead of QVector, and it still passes both requirements tests, then whether QList is as bad as Marc says it is (I have no reason to doubt him) makes no difference. If you replace QList with QVector and rename it QList and my application still passes both tests, then not only will I not complain, I won't know about it unless I reread the documentation. So if we can make that guarantee, then let's just make the switch. Aside: I'm from that bygone era long before Qt, when a "list" in computer programming always meant linked list. A sequence of contiguous data entries was an array. There were no exceptions. So even now, after using QList for more than a decade, I still forget that it's not a linked list. martin ________________________________ From: Development on behalf of Robin Burchell Sent: Monday, March 20, 2017 1:13:23 PM To: development at qt-project.org Subject: Re: [Development] QList Hi Philippe, On Mon, Mar 20, 2017, at 09:28 AM, Philippe wrote: > >>Even our API guidelines stipulate that you should make common things easy and > >>not-so-common things possible. Sharing is _not_ common and it need not be as > >> easy as common tasks. I > > Maybe for you, but in my works, sharing _is_ common, convenient and safe. > And overal usage of COW is one of the concept that makes Qt stand apart. > From my POV, COW largely pay off its minimal performance cost. > When performance is a high priority, _an uncommon case_, then using > alternate containers is always possible and we don't need Qt for this. I don't know your background, but let's assume you are primarily a user of Qt (thus: an application developer of some kind), you may consider performance to be unimportant, or important only in isolated areas of your application. Consider, however, the point of view from many of the people on this list: as Qt uses itself in its own implementation, Qt must have acceptable performance for end user applications to be able to have acceptable performance at all - whether or not it is a priority to those developers. A few concrete examples of where data types matter a lot: signal connections (involves storing a bunch of data), QObject (particularly QObject::children, as already mentioned), event handling from the operating system (or the application itself: the event posting mechanism in QCoreApplication)... > And when size matters, have this in mind: > > sizeof(std::vector) == 32 > sizeof(QVector) == 8 > sizeof(QList) == 8 To provide a more helpful response than Marc's: I assume that you are aware that the Qt types just contain a pointer to a thing which contains the actual data (unlike std::vector), right? That is, QVector is actually (snipped from source): template class QVector { typedef QTypedArrayData Data; Data *d; } Where QTypedArrayData is a QArrayData, which is: struct Q_CORE_EXPORT QArrayData { QtPrivate::RefCount ref; int size; uint alloc : 31; uint capacityReserved : 1; qptrdiff offset; } If I'm adding it up right, this gives me a total cost of 32 bytes on my system. Although the real cost is actually higher I'd guess, due to the two being allocated in separate pieces (given that malloc usually has some kind of book-keeping overhead). Robin -- Robin Burchell robin at crimson.no _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdieter at math.unl.edu Mon Mar 20 13:55:02 2017 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 20 Mar 2017 07:55:02 -0500 Subject: [Development] Need advise on acceptable timeouts for autotests References: <201703161000.55480.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > Hi, > > We repeatedly have the problem that timeouts that developers think are > ample (because they exceed typical runtime by, say, two orders of > magnitude) are found to be insufficient on the CI. > > Latest example: > http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1489618366 > > The timeout to run update-mime-database was recently increased to 2mins. > But that still does not seem to be enough. For a call that hardly takes a > second to run on unloaded machines. May be relevant: Recent versions of update-mime-database do (imo needless) fsync writes, which can make it take up to 30-50 seconds on some systems. See also: http://bugs.freedesktop.org/show_bug.cgi?id=70366 One can opt-out of that setting: PKGSYSTEM_ENABLE_FSYNC=0 which may be desirable for tests such as these. -- Rex From marc.mutz at kdab.com Mon Mar 20 14:13:30 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 20 Mar 2017 14:13:30 +0100 Subject: [Development] QList In-Reply-To: References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <1490012003.2674178.917020488.488D5BF3@webmail.messagingengine.com> Message-ID: <201703201413.30953.marc.mutz@kdab.com> On Monday 20 March 2017 13:42:09 Martin Smith wrote: > >Qt must have acceptable performance for end user applications to be able > >to have acceptable performance at all - whether or not it is a priority > >to those developers. > > I write an application that has two performance requirements: > > 1. It must complete execution in 1 minute. > > 2. It must not run out of memory. Sorry for highjacking your mail, I know this is hardly related, but seeing "application" here, I need to repeat the following: We're talking about Qt here. Qt is not an application. Qt is a library. Different users use it differently. You cannot predict what will be the bottleneck for any given user, thus you have to optimise everything. We don't have the man-power to optimise everything, so we must settle for _not pessimising_ anything. But Qt in the past has pessimised way too much, be it Q_FOREACH, QList, CoW, ... We need to stop pessimising the common tasks to optimize uncommon ones. If someone copies a std::vector with a million elements by value in a tight loop, any profiler in the world will be able to pinpoint that hotspot, and the developer is happy, because the fix is easy. OTOH, no profiler in the world will ever pinpoint to the developer the slowdown caused by using QVector or QList in normal usage patterns. As a result of Qt's sloppiness, your application is 2x slower than it could be, with no indication as to why. You need to have good luck and a very powerful (and expensive) profiler to have a chance to find that QVector performs worse than std::vector in general. Worse, you can't do anything about it, because replacing one QVector with std::vector has neglible effect. With luck, if you replaced all you'd get a 20% speedup (I'm totally making these numbers up), which disqualifies this work for an application developer as having deminishing return of investment. It's not the application developer's task to avoid the death by a thousands Qt paper cuts. It's Qt's job. Our job. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From Martin.Smith at qt.io Mon Mar 20 14:25:56 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 20 Mar 2017 13:25:56 +0000 Subject: [Development] QList In-Reply-To: <201703201413.30953.marc.mutz@kdab.com> References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <1490012003.2674178.917020488.488D5BF3@webmail.messagingengine.com> , <201703201413.30953.marc.mutz@kdab.com> Message-ID: >It's not the application developer's task to avoid the death by a thousands Qt >paper cuts. It's Qt's job. Ok, but I'm the customer, and I am always right. I want my application that uses QList to continue to run in Qt 6 with QList just like it did in Qt 5. If it speeds up or slows down or uses more memory or less, I don't care as long as it still passes my old requirements. What is your solution? martin ________________________________ From: Development on behalf of Marc Mutz Sent: Monday, March 20, 2017 2:13:30 PM To: development at qt-project.org Subject: Re: [Development] QList On Monday 20 March 2017 13:42:09 Martin Smith wrote: > >Qt must have acceptable performance for end user applications to be able > >to have acceptable performance at all - whether or not it is a priority > >to those developers. > > I write an application that has two performance requirements: > > 1. It must complete execution in 1 minute. > > 2. It must not run out of memory. Sorry for highjacking your mail, I know this is hardly related, but seeing "application" here, I need to repeat the following: We're talking about Qt here. Qt is not an application. Qt is a library. Different users use it differently. You cannot predict what will be the bottleneck for any given user, thus you have to optimise everything. We don't have the man-power to optimise everything, so we must settle for _not pessimising_ anything. But Qt in the past has pessimised way too much, be it Q_FOREACH, QList, CoW, ... We need to stop pessimising the common tasks to optimize uncommon ones. If someone copies a std::vector with a million elements by value in a tight loop, any profiler in the world will be able to pinpoint that hotspot, and the developer is happy, because the fix is easy. OTOH, no profiler in the world will ever pinpoint to the developer the slowdown caused by using QVector or QList in normal usage patterns. As a result of Qt's sloppiness, your application is 2x slower than it could be, with no indication as to why. You need to have good luck and a very powerful (and expensive) profiler to have a chance to find that QVector performs worse than std::vector in general. Worse, you can't do anything about it, because replacing one QVector with std::vector has neglible effect. With luck, if you replaced all you'd get a 20% speedup (I'm totally making these numbers up), which disqualifies this work for an application developer as having deminishing return of investment. It's not the application developer's task to avoid the death by a thousands Qt paper cuts. It's Qt's job. Our job. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Mon Mar 20 14:52:40 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 20 Mar 2017 14:52:40 +0100 Subject: [Development] QList In-Reply-To: References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703201413.30953.marc.mutz@kdab.com> Message-ID: <201703201452.41338.marc.mutz@kdab.com> On Monday 20 March 2017 14:25:56 Martin Smith wrote: > >It's not the application developer's task to avoid the death by a > >thousands Qt > > > >paper cuts. It's Qt's job. > > Ok, but I'm the customer, and I am always right. I want my application that > uses QList to continue to run in Qt 6 with QList just like it did in Qt 5. > If it speeds up or slows down or uses more memory or less, I don't care as > long as it still passes my old requirements. > > > What is your solution? I have answered that question five years ago[1]: If your interests are against the common good, you should pay the prize, not expect it to be communitised. So, e.g.: Pay twice the fees to use a compatibility QList until Qt 7 or pay the normal price and port, possibly with an automated tool a la clang- modermize. [1] https://marcmutz.wordpress.com/2011/09/20/c98-support-costs-extra/ -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From ville.voutilainen at gmail.com Mon Mar 20 14:52:36 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Mon, 20 Mar 2017 15:52:36 +0200 Subject: [Development] QList In-Reply-To: <201703201452.41338.marc.mutz@kdab.com> References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703201413.30953.marc.mutz@kdab.com> <201703201452.41338.marc.mutz@kdab.com> Message-ID: On 20 March 2017 at 15:52, Marc Mutz wrote: > So, e.g.: Pay twice the fees to use a compatibility QList until Qt 7 or pay > the normal price and port, possibly with an automated tool a la clang- > modermize. And if I want to run the same code with Qt 5 and Qt 6? I don't want to modernize it, since that may change or break what it does on Qt 5, and I also don't want to modernize code as part of my build in a dynamic fashion, because that costs time and can cause version control problems. If we want Qt to be a library that caters to various different user scenarios, we should first stop assuming that one-way modernization tools are a realistic solution to compatibility problems. From philwave at gmail.com Mon Mar 20 15:10:21 2017 From: philwave at gmail.com (Philippe) Date: Mon, 20 Mar 2017 15:10:21 +0100 Subject: [Development] QList In-Reply-To: <1490012003.2674178.917020488.488D5BF3@webmail.messagingengine.com> References: <20170320092832.2712.6F0322A@gmail.com> <1490012003.2674178.917020488.488D5BF3@webmail.messagingengine.com> Message-ID: <20170320151020.603A.6F0322A@gmail.com> Concerning sizeof(QVector) == 8 Alone, this is of course neglictable in a process space. But this allows to use QVector inexpensively as a member variable in objects that are instantiated many thousands of times (and in scenarios when this member is often unused). Yes I am aware of the QVector internals. As an old DSP and real-time graphics programmer, I came to know a lot about performances. I even have my own vector classes. This means, I also know when I can get relaxed on the performance matter, and rather select convenience and readability. And I thanks Qt (so far), to provide me that convenience. Philippe > > And when size matters, have this in mind: > > > > sizeof(std::vector) == 32 > > sizeof(QVector) == 8 > > sizeof(QList) == 8 > > To provide a more helpful response than Marc's: I assume that you are > aware that the Qt types just contain a pointer to a thing which contains > the actual data (unlike std::vector), right? > > That is, QVector is actually (snipped from source): > template > class QVector > { > typedef QTypedArrayData Data; > Data *d; > } > > Where QTypedArrayData is a QArrayData, which is: > struct Q_CORE_EXPORT QArrayData > { > QtPrivate::RefCount ref; > int size; > uint alloc : 31; > uint capacityReserved : 1; > qptrdiff offset; > } > > If I'm adding it up right, this gives me a total cost of 32 bytes on my > system. Although the real cost is actually higher I'd guess, due to the > two being allocated in separate pieces (given that malloc usually has > some kind of book-keeping overhead). > > Robin > > -- > Robin Burchell > robin at crimson.no > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Mon Mar 20 15:19:32 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 20 Mar 2017 15:19:32 +0100 Subject: [Development] QList In-Reply-To: References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703201452.41338.marc.mutz@kdab.com> Message-ID: <201703201519.32661.marc.mutz@kdab.com> On Monday 20 March 2017 14:52:36 Ville Voutilainen wrote: > On 20 March 2017 at 15:52, Marc Mutz wrote: > > So, e.g.: Pay twice the fees to use a compatibility QList until Qt 7 or > > pay the normal price and port, possibly with an automated tool a la > > clang- modermize. > > And if I want to run the same code with Qt 5 and Qt 6? I don't want to > modernize it, > since that may change or break what it does on Qt 5, and I also don't > want to modernize code > as part of my build in a dynamic fashion, because that costs time and can > cause version control problems. If we want Qt to be a library that caters > to various different > user scenarios, we should first stop assuming that one-way > modernization tools are > a realistic solution to compatibility problems. That from someone that just broke an awful lot of lines of C++ code by making noexcept be part of the function type :P Well, seriously. My answer is the same: Time has only one direction. Qt source and binary compatibility only has one direction. If you want to use Qt in a way it was not intended to be used, then you need to pay the prize, and not ask the community to do so for you. You can pay by porting to QVector. Or auto. That will work in Qt 5 and Qt 6. You can define your own MyQListOrQVector type alias. Or you can #ifdef. It's up to you. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From ville.voutilainen at gmail.com Mon Mar 20 15:38:28 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Mon, 20 Mar 2017 16:38:28 +0200 Subject: [Development] QList In-Reply-To: <201703201519.32661.marc.mutz@kdab.com> References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703201452.41338.marc.mutz@kdab.com> <201703201519.32661.marc.mutz@kdab.com> Message-ID: On 20 March 2017 at 16:19, Marc Mutz wrote: >> And if I want to run the same code with Qt 5 and Qt 6? I don't want to >> modernize it, >> since that may change or break what it does on Qt 5, and I also don't >> want to modernize code >> as part of my build in a dynamic fashion, because that costs time and can >> cause version control problems. If we want Qt to be a library that caters >> to various different >> user scenarios, we should first stop assuming that one-way >> modernization tools are >> a realistic solution to compatibility problems. > > That from someone that just broke an awful lot of lines of C++ code by making > noexcept be part of the function type :P Perhaps we shouldn't get on that side track, but *I* didn't do it, I'm not entirely convinced it broke "an awful lot of lines of code", and it indeed specifically did not and does not break very vast swaths of existing code, because *every* function call still behaves as they did before, although certain pointer conversions don't. It certainly doesn't produce a fear that it would break "the whole world". > Well, seriously. My answer is the same: Time has only one direction. Qt source > and binary compatibility only has one direction. If you want to use Qt in a > way it was not intended to be used, then you need to pay the prize, and not > ask the community to do so for you. > > You can pay by porting to QVector. Or auto. That will work in Qt 5 and Qt 6. > You can define your own MyQListOrQVector type alias. Or you can #ifdef. It's > up to you. That's great, but before I have migrated all my code to any of those, it's simply better to change QList to be a QVector, fix the cases that require reference stability (which you're already doing in some places) to use a different type, deprecate direct uses of QList and *then* _eventually_ remove QList altogether, rather than doing it without any grace period. From konrad at silmor.de Mon Mar 20 15:56:38 2017 From: konrad at silmor.de (Konrad Rosenbaum) Date: Mon, 20 Mar 2017 15:56:38 +0100 Subject: [Development] QList In-Reply-To: <201703201519.32661.marc.mutz@kdab.com> References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703201452.41338.marc.mutz@kdab.com> <201703201519.32661.marc.mutz@kdab.com> Message-ID: On Mon, March 20, 2017 15:19, Marc Mutz wrote: > Well, seriously. My answer is the same: Time has only one direction. Qt > source > and binary compatibility only has one direction. If you want to use Qt in > a > way it was not intended to be used, then you need to pay the prize, and > not > ask the community to do so for you. > > You can pay by porting to QVector. Or auto. That will work in Qt 5 and Qt > 6. > You can define your own MyQListOrQVector type alias. Or you can #ifdef. > It's > up to you. Marc, please do not underestimate the impact of laziness! Whether we admit it or not: most of us became computer scientists because we're lazy - we want to let the machine work for us! ;-) Everybody else at least works for for someone who is quite tight-fisted with the budget. In other words: if Qt 6 forces me to do any significant amount of porting, then I'll stay with Qt 5. I was able to port my biggest Qt 4 application to Qt 5 because I could promise my client it'd be done in a couple of days and he'd gain lots of features too. If I have to replace every single occurrence of QList with QVector or auto for it to continue working with Qt 6, then I will not get a budget for that. The community will pay for my laziness by having to support an outdated framework for much longer. Lazy people are great at externalizing... :-P Konrad From lars.knoll at qt.io Mon Mar 20 16:10:53 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 20 Mar 2017 15:10:53 +0000 Subject: [Development] QList In-Reply-To: References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703201452.41338.marc.mutz@kdab.com> <201703201519.32661.marc.mutz@kdab.com> Message-ID: > On 20 Mar 2017, at 15:56, Konrad Rosenbaum wrote: > > On Mon, March 20, 2017 15:19, Marc Mutz wrote: >> Well, seriously. My answer is the same: Time has only one direction. Qt >> source >> and binary compatibility only has one direction. If you want to use Qt in >> a >> way it was not intended to be used, then you need to pay the prize, and >> not >> ask the community to do so for you. >> >> You can pay by porting to QVector. Or auto. That will work in Qt 5 and Qt >> 6. >> You can define your own MyQListOrQVector type alias. Or you can #ifdef. >> It's >> up to you. > > Marc, please do not underestimate the impact of laziness! Whether we admit > it or not: most of us became computer scientists because we're lazy - we > want to let the machine work for us! ;-) > > Everybody else at least works for for someone who is quite tight-fisted > with the budget. > > In other words: if Qt 6 forces me to do any significant amount of porting, > then I'll stay with Qt 5. I was able to port my biggest Qt 4 application > to Qt 5 because I could promise my client it'd be done in a couple of days > and he'd gain lots of features too. > > If I have to replace every single occurrence of QList with QVector or auto > for it to continue working with Qt 6, then I will not get a budget for > that. > > The community will pay for my laziness by having to support an outdated > framework for much longer. Lazy people are great at externalizing... :-P I fully agree with you here Konrad. I've seen the pain our customers had to go through when moving from Qt 3 to Qt 4, and I do not want to repeat this. We need to make moving to Qt 6 as painless as possible for our users, otherwise we'll have many people stuck in 5.x for a very long time. And that's very costly for both us and our users. This means we have to be careful with any changes that could break large amounts of source code. So QList will have to exist as a type in Qt 6 with an API that is as source compatible to the one in Qt 5 as we can make it, while we need to still try to deprecate it for new code and offer better alternatives. We'll need to try it out, but so far making QList an alias to QVector sounds like the most likely approach we could take. Cheers, Lars From thiago.macieira at intel.com Mon Mar 20 16:29:37 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 20 Mar 2017 08:29:37 -0700 Subject: [Development] Who's responsible for 3rdparty these days (QTBUG-59586)? In-Reply-To: References: <1923287.X8lTtAKxnU@tjmaciei-mobl1> Message-ID: <1614254.lE1TAYjZoS@tjmaciei-mobl1> On segunda-feira, 20 de março de 2017 03:47:44 PDT Kai Koehne wrote: > I don't think this is the case. Every contributor can upload patches with > new third party code, as long as this is properly documented. > > Only maintainers are allowed to approve them though, and if you want to add > new third party code to the Qt libraries, tools or plugins you need an > approval by Lars. The Contribution Licence Agreement states otherwise. Please adjust the QUIP to match the text from section 2.3 of the CLA. Specifically, it states that 3rdparty must be approved by the Chief Maintainer and the Qt Company in written form. Because of this hurdle, I have no intention of maintaining someoe else's 3rdparty code. forkfd is the only exception I make, but it's also something I wrote myself, so it's "1stparty" not "3rdparty". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Mar 20 16:36:20 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 20 Mar 2017 08:36:20 -0700 Subject: [Development] QList In-Reply-To: <201703200909.58409.marc.mutz@kdab.com> References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703200909.58409.marc.mutz@kdab.com> Message-ID: <6040650.fnXmUlFth0@tjmaciei-mobl1> On segunda-feira, 20 de março de 2017 01:09:57 PDT Marc Mutz wrote: > It's a fallacy to think that there's a lot of need to return a shared > collection from APIs. Either you create the collection on request, then an > exclusive collection would be preferable, as returning it from a function is > free[1], or you "return" internal state, in which case returning some form > of view (incl. the case of simply adding begin()/end()) would be the way to > go (cf. https://codereview.qt-project.org/150658). We disagree and clearly I don't think it's a fallacy. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From markg85 at gmail.com Mon Mar 20 17:14:30 2017 From: markg85 at gmail.com (Mark Gaiser) Date: Mon, 20 Mar 2017 17:14:30 +0100 Subject: [Development] QList In-Reply-To: <201703181051.07307.marc.mutz@kdab.com> References: <201703181051.07307.marc.mutz@kdab.com> Message-ID: On Sat, Mar 18, 2017 at 10:51 AM, Marc Mutz wrote: > On Saturday 18 March 2017 09:06:09 Ville Voutilainen wrote: >> There's been a fair amount of talk about QList's future, so I'm curious: >> >> 1) What are the problems with QList? > > See Konstantin's reply. For me, the performance issue is pretty strong > already, but that stability of references into QLists may depend on such > subtleties as the machine's word size or whether Q_DECLARE_TYPEINFO has been > called for the type is also a big correctness issue. > >> 2) What do we plan to do about those problems? > > Kill QList in Qt 6. > >> 3) How do we expect to migrate code that uses it? > > Possibly provide a QArrayList that _always_ uses the heap, and thus _always_ > provides stability of references. There's some code that actually depends on > stability of references (QToolBox, e.g.). > > Try to minimize use in new code. That hasn't worked out as planned. Look at > the dates of my two contributions Konstantin linked to, then look at the API > reviews for 5.9. It's almost guarateed that Q_DECLARE_TYPEINFO (or the similar > Q_DECLARE_SHARED) have been "forgotten". Review regularly fails for such > things. > > This experience, over several years, has thaught me that we need a technical > solution. And so we started to specialize QList as an empty class. > So far, this is the only workable solution I have found, and believe me, I am > very determined. > > I think we should do this for all new (non-polymorphic) classes. > > And since we now depend on enough C++11, replacing QList with QVector in > generic code is trivial: either use auto, or when you can't, use > QListOrVector, introduced here: https://codereview.qt-project.org/188858 > > So, here's my proposal for a QList exit strategy: > > In Qt 5: > > 1. Replace QList in generic code by QListOrVector, tell users to hold QLists > they get from Qt API only in type-deduced variables. > 2. Fix any QList API missing (and not actively harmful) on QVector. E.g. I > don't think toSet() should be either on QList nor QVector, because it > creates nonsense like qHash(QItemSelectionRange) (please, please, look it > up :) > 3. Disable QList for all new QFoo value types (by specializing QList as > an empty class). > 4. Provide QArrayList for code that needs stability of references (stability > statically checked in Qt 5, enforced in Qt 6). > > In Qt 6: > > 5. Replace all QList uses left with ... what ? QVector? std::vector? > -> separate discussion > 6. Kill QList or keep it as a deprecated class. > > Thanks, > Marc Hi Marc, I'm fine with replacing QList usages with QVector in codebases i maintain, but even with the latest Qt version, that isn't always possible or convenient. For instance, at this very moment i want a QVector with all keys from a given map (QMap) but Qt itself doesn't provide a direct way of doing that. The keys method on the map returns a QList. QList has a "toVector" method which gives me the QVector i want. It works, yes. But it's really indirect. The key kinda has to be unique in a map (and hash) so it would be perfectly fine for it to be a QVector, but it isn't. Is there a technical reason for it or is it just because of Qt's history? From andreas.aardal.hanssen at gmail.com Mon Mar 20 17:29:44 2017 From: andreas.aardal.hanssen at gmail.com (Andreas Aardal Hanssen) Date: Mon, 20 Mar 2017 17:29:44 +0100 Subject: [Development] QList In-Reply-To: References: <201703181051.07307.marc.mutz@kdab.com> Message-ID: <82746B35-46BF-430C-BA5D-B394FB9CAF3F@gmail.com> > 20. mar. 2017 kl. 17.14 skrev Mark Gaiser : > On Sat, Mar 18, 2017 at 10:51 AM, Marc Mutz > wrote: >> 6. Kill QList or keep it as a deprecated class. >> Thanks, >> Marc > Hi Marc, > I'm fine with replacing QList usages with QVector in codebases i > maintain, but even with the latest Qt version, that isn't always > possible or convenient. > For instance, at this very moment i want a QVector with all keys from > a given map (QMap) but Qt itself doesn't provide a > direct way of doing that. I would probably use QDateTime(date).toMSecsSinceEpoch() or something similar as a key in such a map. It’s very hard to provide good default behavior for code that is inefficient at its core. In this case, QList and QVector would perform fairly similarly for both cases I /think/. Meaning for an integer key which is behaviourally equivalent but vastly more efficient, QList and QVector would store them the same way. Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Mon Mar 20 17:40:07 2017 From: scott at towel42.com (Scott Aron Bloom) Date: Mon, 20 Mar 2017 16:40:07 +0000 Subject: [Development] QList In-Reply-To: References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703201452.41338.marc.mutz@kdab.com> <201703201519.32661.marc.mutz@kdab.com> Message-ID: -----Original Message----- From: Development [mailto:development-bounces+scott=towel42.com at qt-project.org] On Behalf Of Konrad Rosenbaum Sent: Monday, March 20, 2017 07:57 To: development at qt-project.org Subject: Re: [Development] QList On Mon, March 20, 2017 15:19, Marc Mutz wrote: > Well, seriously. My answer is the same: Time has only one direction. > Qt source and binary compatibility only has one direction. If you want > to use Qt in a way it was not intended to be used, then you need to > pay the prize, and not ask the community to do so for you. > > You can pay by porting to QVector. Or auto. That will work in Qt 5 and > Qt 6. > You can define your own MyQListOrQVector type alias. Or you can #ifdef. > It's > up to you. Marc, please do not underestimate the impact of laziness! Whether we admit it or not: most of us became computer scientists because we're lazy - we want to let the machine work for us! ;-) Everybody else at least works for for someone who is quite tight-fisted with the budget. In other words: if Qt 6 forces me to do any significant amount of porting, then I'll stay with Qt 5. I was able to port my biggest Qt 4 application to Qt 5 because I could promise my client it'd be done in a couple of days and he'd gain lots of features too. If I have to replace every single occurrence of QList with QVector or auto for it to continue working with Qt 6, then I will not get a budget for that. The community will pay for my laziness by having to support an outdated framework for much longer. Lazy people are great at externalizing... :-P ========== +1 I had customers on Qt3 for 2 years after Qt4 came out for this reason alone, the cost of moving to Qt4 was too large for them to justify the expense. When it came to 4 to 5, it was minimal, in fact none of my customers "held on to 4" because of the migration path, however, many simply waited for a reason. Now, myself, and a few others are sitting on Qt 5.5 because of the issues with the web browser change in 5.6... but that's another issue.... Scott From frank at hemer.org Mon Mar 20 17:52:40 2017 From: frank at hemer.org (Frank Hemer) Date: Mon, 20 Mar 2017 17:52:40 +0100 Subject: [Development] QList In-Reply-To: References: <3222957.Av71qoJJfk@tjmaciei-mobl1> Message-ID: <1875338.BllZTCp9G0@master> On Monday 20 March 2017 16:40:07 Scott Aron Bloom wrote: > -----Original Message----- > From: Development > [mailto:development-bounces+scott=towel42.com at qt-project.org] On Behalf Of > Konrad Rosenbaum Sent: Monday, March 20, 2017 07:57 > To: development at qt-project.org > Subject: Re: [Development] QList > > On Mon, March 20, 2017 15:19, Marc Mutz wrote: > > Well, seriously. My answer is the same: Time has only one direction. > > Qt source and binary compatibility only has one direction. If you want > > to use Qt in a way it was not intended to be used, then you need to > > pay the prize, and not ask the community to do so for you. > > > > You can pay by porting to QVector. Or auto. That will work in Qt 5 and > > Qt 6. > > You can define your own MyQListOrQVector type alias. Or you can #ifdef. > > It's > > up to you. > > Marc, please do not underestimate the impact of laziness! Whether we admit > it or not: most of us became computer scientists because we're lazy - we > want to let the machine work for us! ;-) > > Everybody else at least works for for someone who is quite tight-fisted with > the budget. > > In other words: if Qt 6 forces me to do any significant amount of porting, > then I'll stay with Qt 5. I was able to port my biggest Qt 4 application to > Qt 5 because I could promise my client it'd be done in a couple of days and > he'd gain lots of features too. > > If I have to replace every single occurrence of QList with QVector or auto > for it to continue working with Qt 6, then I will not get a budget for > that. > > The community will pay for my laziness by having to support an outdated > framework for much longer. Lazy people are great at externalizing... :-P > ========== > +1 > > I had customers on Qt3 for 2 years after Qt4 came out for this reason alone, > the cost of moving to Qt4 was too large for them to justify the expense. > > When it came to 4 to 5, it was minimal, in fact none of my customers "held > on to 4" because of the migration path, however, many simply waited for a > reason. > > Now, myself, and a few others are sitting on Qt 5.5 because of the issues > with the web browser change in 5.6... but that's another issue.... +1 And QtScript being the next 'another' issue on the horizon ... Frank From marc.mutz at kdab.com Mon Mar 20 18:40:59 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 20 Mar 2017 18:40:59 +0100 Subject: [Development] QList In-Reply-To: References: <201703181051.07307.marc.mutz@kdab.com> Message-ID: <201703201841.00116.marc.mutz@kdab.com> Hi other-Mark, On Monday 20 March 2017 17:14:30 Mark Gaiser wrote: > I'm fine with replacing QList usages with QVector in codebases i > maintain, but even with the latest Qt version, that isn't always > possible or convenient. > For instance, at this very moment i want a QVector with all keys from > a given map (QMap) but Qt itself doesn't provide a > direct way of doing that. What's a "direct way"? Don't assume there's a member function for everything you'd ever want to do with a container. Such folly has led to QList::toSet(), which, in turn has led to // needed for QList::toSet() to compile uint qHash(const QItemSelectionRange &, uint = 0) { return 0; } > The keys method on the map returns a QList. > QList has a "toVector" method which gives me the QVector i want. > > It works, yes. But it's really indirect. template QVector keys(const QHash &hash) { QVector result; result.reserve(hash.size()); for (auto it = hash.begin(), end = hash.end(), it != end; ++it) result.append(it.key()); return result; } // ... same for QMap ... template QVector keys(const std::unordered_map &hash) { QVector result; result.reserve(hash.size()); for (const auto &p : hash) result.append(p.first); return result; } You write these functions once, put them in your util.h, and are done with it. It's the same for STL: https://github.com/KDE/libkleo/blob/2fe48b77ba61fada80eaace8cb71dd0fd13265ae/src/kleo/stl_util.h That file evolved through half a dozen projects. > The key kinda has to be unique in a map (and hash) so it would be > perfectly fine for it to be a QVector, but it isn't. > Is there a technical reason for it or is it just because of Qt's history? Just because of Qt's history of preferring QList for everything. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Mon Mar 20 18:51:49 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 20 Mar 2017 18:51:49 +0100 Subject: [Development] QList In-Reply-To: References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703201519.32661.marc.mutz@kdab.com> Message-ID: <201703201851.50521.marc.mutz@kdab.com> On Monday 20 March 2017 15:38:28 Ville Voutilainen wrote: > On 20 March 2017 at 16:19, Marc Mutz wrote: > >> And if I want to run the same code with Qt 5 and Qt 6? I don't want to > >> modernize it, > >> since that may change or break what it does on Qt 5, and I also don't > >> want to modernize code > >> as part of my build in a dynamic fashion, because that costs time and > >> can cause version control problems. If we want Qt to be a library that > >> caters to various different > >> user scenarios, we should first stop assuming that one-way > >> modernization tools are > >> a realistic solution to compatibility problems. > > > > That from someone that just broke an awful lot of lines of C++ code by > > making noexcept be part of the function type :P > > Perhaps we shouldn't get on that side track, but *I* didn't do it, I'm > not entirely convinced > it broke "an awful lot of lines of code", and it indeed specifically > did not and does not break very > vast swaths of existing code, because *every* function call still > behaves as they did before, > although certain pointer conversions don't. It certainly doesn't > produce a fear that > it would break "the whole world". I was just pulling your leg :) Though it certainly broke a lot of Qt code and we're still recovering: 5a1b4832a2704e7fb386d6b4c73dab85facdc40b (QObject, QTimer) c5e687895dd2eba3106f697b6e92b84683402403 (QtConcurrent; incomplete) it looks like every class that provides new-style connect syntax should be affected. Yes, we're to blame to not have centered this functionality in a qInvoke() template before, and maybe it's time to do that, but I certainly do not remember such a large SiC in C++ ever before. Well, in the last 17 years. > > Well, seriously. My answer is the same: Time has only one direction. Qt > > source and binary compatibility only has one direction. If you want to > > use Qt in a way it was not intended to be used, then you need to pay the > > prize, and not ask the community to do so for you. > > > > You can pay by porting to QVector. Or auto. That will work in Qt 5 and Qt > > 6. You can define your own MyQListOrQVector type alias. Or you can > > #ifdef. It's up to you. > > That's great, but before I have migrated all my code to any of those, > it's simply better > to change QList to be a QVector, fix the cases that require reference > stability (which you're > already doing in some places) to use a different type, deprecate > direct uses of QList > and *then* _eventually_ remove QList altogether, rather than doing it > without any grace > period. When I said "Kill QList in Qt 6", I mean eradicate it from our APIs. The name, too. Whether the QList class lives on to support legacy code is a different question. As long as it's deprecated, and maybe moved to a Qt5Support module (that name will have raised some hairs now :), I'm fine with that. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Mon Mar 20 19:04:36 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 20 Mar 2017 19:04:36 +0100 Subject: [Development] QList In-Reply-To: References: <3222957.Av71qoJJfk@tjmaciei-mobl1> Message-ID: <201703201904.37466.marc.mutz@kdab.com> On Monday 20 March 2017 16:10:53 Lars Knoll wrote: > This means we have to be careful with any changes that could break large > amounts of source code. So QList will have to exist as a type in Qt 6 with > an API that is as source compatible to the one in Qt 5 as we can make it, > while we need to still try to deprecate it for new code and offer better > alternatives. "Deprecate for new code"? What does that mean, exactly? -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Mon Mar 20 19:09:03 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 20 Mar 2017 11:09:03 -0700 Subject: [Development] QList In-Reply-To: <201703201851.50521.marc.mutz@kdab.com> References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703201851.50521.marc.mutz@kdab.com> Message-ID: <1948718.VOqfqNGyKj@tjmaciei-mobl1> Em segunda-feira, 20 de março de 2017, às 10:51:49 PDT, Marc Mutz escreveu: > Though it certainly broke a lot of Qt code and we're still recovering: > > 5a1b4832a2704e7fb386d6b4c73dab85facdc40b (QObject, QTimer) > c5e687895dd2eba3106f697b6e92b84683402403 (QtConcurrent; incomplete) > > it looks like every class that provides new-style connect syntax should be > affected. Yes, we're to blame to not have centered this functionality in a > qInvoke() template before, and maybe it's time to do that, but I certainly > do not remember such a large SiC in C++ ever before. Well, in the last 17 > years. Would not have been an issue if we were using std::function, though. Then again, it might have been an issue if we *were* using std::function from a C++ standard library that did not update to noexcept with a C++ compiler that did (such as when using Clang on Linux with libstdc++). Since this error would have shown up in the user's code, we would have washed our hands and told the user "upgrade your C++ standard library, downgrade your compiler or stop using C++17". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ville.voutilainen at gmail.com Mon Mar 20 19:11:47 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Mon, 20 Mar 2017 20:11:47 +0200 Subject: [Development] QList In-Reply-To: <201703201851.50521.marc.mutz@kdab.com> References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703201519.32661.marc.mutz@kdab.com> <201703201851.50521.marc.mutz@kdab.com> Message-ID: On 20 March 2017 at 19:51, Marc Mutz wrote: >> Perhaps we shouldn't get on that side track, but *I* didn't do it, I'm >> not entirely convinced >> it broke "an awful lot of lines of code", and it indeed specifically >> did not and does not break very >> vast swaths of existing code, because *every* function call still >> behaves as they did before, >> although certain pointer conversions don't. It certainly doesn't >> produce a fear that >> it would break "the whole world". > > I was just pulling your leg :) That doesn't make the analogy more correct. :P > Though it certainly broke a lot of Qt code and we're still recovering: > > 5a1b4832a2704e7fb386d6b4c73dab85facdc40b (QObject, QTimer) > c5e687895dd2eba3106f697b6e92b84683402403 (QtConcurrent; incomplete) It can certainly break function wrappers. >> > You can pay by porting to QVector. Or auto. That will work in Qt 5 and Qt >> > 6. You can define your own MyQListOrQVector type alias. Or you can >> > #ifdef. It's up to you. >> >> That's great, but before I have migrated all my code to any of those, >> it's simply better >> to change QList to be a QVector, fix the cases that require reference >> stability (which you're >> already doing in some places) to use a different type, deprecate >> direct uses of QList >> and *then* _eventually_ remove QList altogether, rather than doing it >> without any grace >> period. > > When I said "Kill QList in Qt 6", I mean eradicate it from our APIs. The name, > too. Whether the QList class lives on to support legacy code is a different > question. As long as it's deprecated, and maybe moved to a Qt5Support module > (that name will have raised some hairs now :), I'm fine with that. Right; I have been laboring under the misconception that you want to completely remove the type, not just remove it from APIs. However, I think it's still better to keep the name in the APIs and change the meaning of the name. That's far from ideal, but it still provides a better compatibility story than eradicating the name from APIs, and we can still take reasonable steps towards eventually eradicating the name. From marc.mutz at kdab.com Mon Mar 20 19:55:14 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 20 Mar 2017 19:55:14 +0100 Subject: [Development] QList In-Reply-To: References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703201851.50521.marc.mutz@kdab.com> Message-ID: <201703201955.15521.marc.mutz@kdab.com> On Monday 20 March 2017 19:11:47 Ville Voutilainen wrote: > However, I think it's still better to > keep the name in the APIs and change > the meaning of the name. That's far from ideal, but it still provides > a better compatibility story than > eradicating the name from APIs, and we can still take reasonable steps > towards eventually eradicating > the name. You want to keep the name used in the API to eventually eradicate the name? Can you explain how the first helps with the latter? -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From perezmeyer at gmail.com Mon Mar 20 19:53:50 2017 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Mon, 20 Mar 2017 15:53:50 -0300 Subject: [Development] Use of std::function in Qt API In-Reply-To: <24435701.t0Ygg1vmXa@maurice> References: <24435701.t0Ygg1vmXa@maurice> Message-ID: <1804385.6UHCisc69D@tonks> On martes, 14 de marzo de 2017 11:32:39 -03 Olivier Goffart wrote: [snip] > So here are the choice: > > 1- Re-implement QFunction, with similar semantic as std::function. > > 2- Lift the constraint that we can't use the stdlib in our ABI > > 3- Do nothing and keep using awkward interface when we need callback. > > > #3 is, as usual, the easier (status quo) and will probably happen. #1 is a > somewhat difficult task, but not that hard. We will just end up with a poor > copy of std::function. #2 was always dismissed in the past, but I think it > should be seriously considered. (quick reply after skimming trough the thread, will read it fully tomorrow hopefully) In the (2) case it will mean that we distro packagers will be forced to change Qt's SONAME. Yeah, the whole of it. There is a way to get (2) implemented: if Qt exposes an std:: function then it can add some of it's SONAME to Qt's own (ugly, but...) So libQt5Core5 would become something like libQt5StdFooCore5 and such. In that way we can [not so easily] do mass rebuilds of all Qt-using stuff. And if this happens it would be *much* better if it's somehow coordinated by Qt upstreams so we can all keep the same SONAME between distros. [not so easily] there is a *huge* amount of code using Qt and every single change would mean weeks of work (at very very *very* least 2 or 3 of them). We need to recompile everything on each arch after all. Oh, and if some non-other Qt api is exposed it should also become part of the SONAME. Not coordinating this at Qt level means that we distros maintainers will be on our own and each of us will do what we can and there will be mayheam between distros' solutions and we will start hating each other and... not a nice situation, really. So if we are going to only expose libstdc++'s API weshould really consider making it part of the SONAME. After all we discussed some time ago that the libstdc++ lib doesn't breaks BC so frequently. Now what exactly we should expose in the SONAME is another issue. -- SlackDeb: velo como un entrenamiento shaolin para geeks, en vez de meditación y tortura física, abstinencia de internet y sexo Horacio Francisco Sebastián "Perrito" Durán Barrionuevo, sobre un viaje que Federico "SlackDeb" Peretti estaba planeando con su novia. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From ville.voutilainen at gmail.com Mon Mar 20 19:55:37 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Mon, 20 Mar 2017 20:55:37 +0200 Subject: [Development] QList In-Reply-To: <201703201955.15521.marc.mutz@kdab.com> References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703201851.50521.marc.mutz@kdab.com> <201703201955.15521.marc.mutz@kdab.com> Message-ID: On 20 March 2017 at 20:55, Marc Mutz wrote: > On Monday 20 March 2017 19:11:47 Ville Voutilainen wrote: >> However, I think it's still better to >> keep the name in the APIs and change >> the meaning of the name. That's far from ideal, but it still provides >> a better compatibility story than >> eradicating the name from APIs, and we can still take reasonable steps >> towards eventually eradicating >> the name. > > You want to keep the name used in the API to eventually eradicate the name? > Can you explain how the first helps with the latter? By changing the implementation under that name and turning the name into an alias, encouraging users to migrate from that name to the name of the real facility, deprecating the legacy name, and then eventually removing the legacy name; in that order. I suppose others have described plans to some extent similar. From thiago.macieira at intel.com Mon Mar 20 20:11:17 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 20 Mar 2017 12:11:17 -0700 Subject: [Development] Use of std::function in Qt API In-Reply-To: <1804385.6UHCisc69D@tonks> References: <24435701.t0Ygg1vmXa@maurice> <1804385.6UHCisc69D@tonks> Message-ID: <1784128.X8e1dRBqdr@tjmaciei-mobl1> Em segunda-feira, 20 de março de 2017, às 11:53:50 PDT, Lisandro Damián Nicanor Pérez Meyer escreveu: > In the (2) case it will mean that we distro packagers will be forced to > change Qt's SONAME. Yeah, the whole of it. Why? We're not changing our ABI. To be clear: we're not proposing replacing what we have right now with std::function, but adding it to new places as the needs arise. The point however is that if libstdc++ does break its ABI, then you'll have to rebuild half the world anyway. The few libraries and applications that did use Qt and were not affected would be the minority. Telling them apart could be a higher cost than just rebuilding -- remember, ALL C++ code links to libstdc++, regardless of whether it was subject to the ABI break or not. And if libstdc++ changes its soname, then you HAVE to rebuild Qt and everything, anyway. > Oh, and if some non-other Qt api is exposed it should also become part of > the SONAME. Again, why? We've exposed C and Xlib API for years and have never had "X11" in the name (or "xcb" now). Tell me of other libraries that follow this naming scheme, because I haven't heard of them. But note I want to limit which API we're allowed to expose. > So if we are going to only expose libstdc++'s API weshould really consider > making it part of the SONAME. After all we discussed some time ago that the > libstdc++ lib doesn't breaks BC so frequently. No, we shouldn't because it's the frigging C++ *Standard* *Library.* EVERY single C++ application links to it, if you as much as used "new" in your code. I've said this before: there's a way to split libstdc++ into two, so that the library providing the base functionality (new/delete, typeinfo, std::exception, cxxabi) is not the same library as the one providing the higher-level functionality. That would allow sharing the base things that all C++ applications and libraries need from the higher level classes, including that of other implementations like libc++. Yet no Linux distribution does that. For 4 years many have provided libc++ without opting to this solution. That tells me they are not interested in providing binary compatibility between libstdc++ and other C++ standard library implementations. As a consequence, if they are not, why should we be? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Mon Mar 20 20:14:59 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 20 Mar 2017 22:14:59 +0300 Subject: [Development] QList In-Reply-To: References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703201452.41338.marc.mutz@kdab.com> <201703201519.32661.marc.mutz@kdab.com> Message-ID: <7869401490037299@web37j.yandex.ru> 20.03.2017, 19:40, "Scott Aron Bloom" : > Now, myself, and a few others are sitting on Qt 5.5 because of the issues with the web browser change in 5.6... but that's another issue.... You should upgrade to QtWebKit TP5 [1], binary builds are available for Qt 5.8 for all supported desktop platforms [1] https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5 -- Regards, Konstantin From lars.knoll at qt.io Mon Mar 20 22:01:54 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 20 Mar 2017 21:01:54 +0000 Subject: [Development] QList In-Reply-To: <201703201904.37466.marc.mutz@kdab.com> References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703201904.37466.marc.mutz@kdab.com> Message-ID: <819AA05D-F560-48FB-90ED-A9F1AC9FBE09@qt.io> > On 20 Mar 2017, at 19:04, Marc Mutz wrote: > > On Monday 20 March 2017 16:10:53 Lars Knoll wrote: >> This means we have to be careful with any changes that could break large >> amounts of source code. So QList will have to exist as a type in Qt 6 with >> an API that is as source compatible to the one in Qt 5 as we can make it, >> while we need to still try to deprecate it for new code and offer better >> alternatives. > > "Deprecate for new code"? What does that mean, exactly? Pretty much the same as just 'deprecate' ;-) We don't use it ourselves anymore in our API (and have hopefully removed in as much as possible in our implementations). Existing user code using the class should continue to work as much as possible (maybe with somewhat different performance characteristics though). Compiler warnings when using it should be there, but people will need an option to turn them off so they don't drown in them. Cheers, Lars From thiago.macieira at intel.com Mon Mar 20 22:19:11 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 20 Mar 2017 14:19:11 -0700 Subject: [Development] Wishes for C++ standard or compilers In-Reply-To: <14194925.OZWiO3H5W7@tjmaciei-mobl1> References: <14194925.OZWiO3H5W7@tjmaciei-mobl1> Message-ID: <5144126.lprWczEdJB@tjmaciei-mobl1> Em sábado, 18 de março de 2017, às 14:20:49 PDT, Thiago Macieira escreveu: > == Containers == > > And then there's what to do with the containers. Here's where Marc's opinion > and mine differ considerably. Aside from the need to maintain source > compatibility, I feel like we should keep our containers and keep implicit > sharing (same solution as for QString). We know COW can be a pessimisation > for performance-sentive code, but the question is whether it is so for > regular developers who don't know how to write performance-sensitive code. > If developers will make mistakes, can we reduce the impact? Here's another wish that I remembered: destructive move a.k.a. relocation. The destructive move is a special case of move in which the source is also detroyed in the process, as opposed to the regular move in which its contents get moved but the destructor is still called and the object is still in a valid (but unspecified) state. Then we have an even more special case of destructive move: trivial destructive move (trivial relocation), which is just a memcpy. A type with trivial move constructor and trivial destructor is trivially relocatable too, since the trivial destructor does nothing and the trivial move constructor is memcpy. However, the trick is to implement the relocation for non-trivial types. Note that this needs the discussion on the lifetime of trivial types to be finished. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Mon Mar 20 23:02:22 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 20 Mar 2017 23:02:22 +0100 Subject: [Development] QList In-Reply-To: <201703181051.07307.marc.mutz@kdab.com> References: <201703181051.07307.marc.mutz@kdab.com> Message-ID: <201703202302.23366.marc.mutz@kdab.com> On Saturday 18 March 2017 10:51:06 Marc Mutz wrote: > 4. Provide QArrayList for code that needs stability of references > (stability statically checked in Qt 5, enforced in Qt 6). There's disagreement over this last part. I have opted to provide a constrained type alias QArrayList that can only be used to alias QLists that already use QListData::IndirectLayout (= pointers to heap-allocated objects). The intent was to allow QArrayList use in existing API. E.g., and I'm not sure I'm proposing this, QList could be renamed to QArrayList because it currently is. And some users may have come to depend on the stability-of-references feature provided by inefficient QLists. A type alias makes this trivial, because it introduces neither SC nor BC. It's simply a way to document, and statically check, that that particular QList has IndirectLayout. The other option would be to copy QList, strip out the optimisation that makes it use layouts other than IndirectLayout and call the result QArrayList. Disadvantages: - migration of QLists used in APIs has to wait until Qt 6 - two almost identical code bases that are very likely to get out of sync, accidentally or intentionally, before one of them gets ditched in Qt 6 - duplicate documentation to write, maintain, explain difference, ... With the type alias, we just need to document the alias. So, updated and refined tail of QList exit strategy would be: 4. Provide a type alias, QArrayList, for QList, constrained on actually QListData::IndirectLayout QLists. Use it to mark QList uses that either a. are (includes QVariant, QModelIndex, QImage, QPixmap, ...) b. should conceptually be (excludes QVariant, QModelIndex, ...) array lists (ie. arrays of pointers to heap-allocated objects) in a BC and SC way. In Qt 6: (the -5- and -6- just refer to the Qt 5 and Qt 6 versions of the names): 5. Q5List -> Q6ArrayList, strip out non-IndirectLayout code, making it always use IndirectLayout. 6. Provide a deprecated type alias Q6List that resolves to either Q6Vector or Q6ArrayList, depending on similar conditions Q5List used before. 7. Replace all Q6List uses in API with either Q6ArrayList or Q6Vector. Advantages: - only one QList implementation to maintain and document in both Qt 5 and 6. - adjustable SC: Because this introduces a SiC/SC knob that's interesting to turn: If Q6List uses the exact same conditions as Q5List, Q6List would have the same layout as Q5List, making 'QList' SC. But Q6List would map to Q6ArrayList while the Qt API very probably will have migrated to Q6Vector, making 'QList' SiC. If we, say, dropped the isLarge trait from the condition, then some Q6List would switch memory layout, breaking stability of references for some UserTypes, compared to Q5List, making 'QList' SiC. But Q6List would map to Q6Vector, making 'QList', QList etc. SC. Not sure where that knob will end up, but it's nice that it's there. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From kevin.kofler at chello.at Mon Mar 20 23:43:12 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 20 Mar 2017 23:43:12 +0100 Subject: [Development] QList References: <201703181051.07307.marc.mutz@kdab.com> <201703201841.00116.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > https://github.com/KDE/libkleo/blob/2fe48b77ba61fada80eaace8cb71dd0fd13265ae/src/kleo/stl_util.h Thanks for proving my point that the STL APIs require tons of copy&paste boilerplate in every project. Kevin Kofler From kevin.kofler at chello.at Mon Mar 20 23:48:14 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 20 Mar 2017 23:48:14 +0100 Subject: [Development] QList References: <201703181051.07307.marc.mutz@kdab.com> <201703202302.23366.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > The other option would be to copy QList, strip out the optimisation that > makes it use layouts other than IndirectLayout and call the result > QArrayList. > > Disadvantages: > > - migration of QLists used in APIs has to wait until Qt 6 > - two almost identical code bases that are very likely to get out of sync, > accidentally or intentionally, before one of them gets ditched in Qt 6 > - duplicate documentation to write, maintain, explain difference, ... > With the type alias, we just need to document the alias. Advantages: - code that needs QArrayList because it assumes stability of references could move to it right now, including the examples you keep bringing up every so often. So it would allow fixing bugs now rather than in Qt 6. Kevin Kofler From marc.mutz at kdab.com Mon Mar 20 23:58:06 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 20 Mar 2017 23:58:06 +0100 Subject: [Development] QList In-Reply-To: References: <201703202302.23366.marc.mutz@kdab.com> Message-ID: <201703202358.06763.marc.mutz@kdab.com> On Monday 20 March 2017 23:48:14 Kevin Kofler wrote: > Advantages: > > - code that needs QArrayList because it assumes stability of references > could move to it right now, including the examples you keep bringing up > every so often. So it would allow fixing bugs now rather than in Qt 6. What example? -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From kevin.kofler at chello.at Tue Mar 21 01:45:53 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 21 Mar 2017 01:45:53 +0100 Subject: [Development] QList References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <201703200909.58409.marc.mutz@kdab.com> <20170320092832.2712.6F0322A@gmail.com> <1490012003.2674178.917020488.488D5BF3@webmail.messagingengine.com> Message-ID: Martin Smith wrote: > Aside: I'm from that bygone era long before Qt, when a "list" in computer > programming always meant linked list. A sequence of contiguous data > entries was an array. There were no exceptions. So even now, after using > QList for more than a decade, I still forget that it's not a linked list. This assumption was already not true with Java 1.2, released December 8, 1998. That release introduced java.util.List as a generic interface to ANY list, including ArrayList. QList was introduced with Qt 4, released June 28, 2005. So it is unfair to blame Qt for not following the obsolete terminology you mention. Kevin Kofler From kevin.kofler at chello.at Tue Mar 21 01:53:46 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 21 Mar 2017 01:53:46 +0100 Subject: [Development] QList References: <201703202302.23366.marc.mutz@kdab.com> <201703202358.06763.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > On Monday 20 March 2017 23:48:14 Kevin Kofler wrote: >> Advantages: >> >> - code that needs QArrayList because it assumes stability of references >> could move to it right now, including the examples you keep bringing up >> every so often. So it would allow fixing bugs now rather than in Qt 6. > > What example? The ones you kept claiming I volunteered to fix. (I did not.) Kevin Kofler From thiago.macieira at intel.com Tue Mar 21 04:57:25 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 20 Mar 2017 20:57:25 -0700 Subject: [Development] QList In-Reply-To: References: <3222957.Av71qoJJfk@tjmaciei-mobl1> Message-ID: <1797438.My2pJYudm9@tjmaciei-mobl1> Em segunda-feira, 20 de março de 2017, às 17:45:53 PDT, Kevin Kofler escreveu: > This assumption was already not true with Java 1.2, released December 8, > 1998. That release introduced java.util.List as a generic interface to ANY > list, including ArrayList. QList was introduced with Qt 4, released June 28, > 2005. So it is unfair to blame Qt for not following the obsolete > terminology you mention. You're forgetting Qt before 4.0. The current QList was introduced with Qt 4, but previous versions had QList too. I can't find the exact release date for 1.0, but it happened some time after 20-May-1995 (0.90) . Qt 1.x still supported compilers without template support (they were common in the early to mid 90s). If you had templates, then QList was a #define to QListT, which derived from QGList ("g" for generic), which was a doubly-linked list of pointers to the item in question. It had virtuals too. That is actually very similar to java.util.List... Qt 1.x also had a QVector (again, also provided as macro), deriving from QGVector, which was a pointer vector. Confusingly, what we now call "vector" was implemented by QArray, which derived from QGArray. QGArray managed only the byte-level array and QArray did the necessary casting to the element type, as well as multiplications and divisions by the element size. Unlike QList and QVector, QArray was reference- counted. QByteArray was typedef'ed to QArray. QString derived from QByteArray but still operated on arbitrary encoding. QBitArray derived from QByteArray. There were also QStrList and QStrVec, which respectively derived from QList and QVector. Qt 2.0 was released on 25-May-1999. Aside from removing support for compilers that didn't support templates, QList, QVector and QArray remained the same. It introduced QValueList, a doubly-linked list of values (not pointers). Like QArray, it was reference-counted. QString was converted to UTF-16 and the old Qt 1 QString became QCString (still deriving from QByteArray). Because of the conversion, QStrList and QStrVec no longer worked with QString, so QStringList was introduced, a specialisation of QValueList. Qt 3.0 was released 11-Oct-2001. Qt 2's QList and QVector were renamed to QPtrList and QPtrVector, while QArray became QMemArray. All three headers had a "compat" macro that would #define the old names, to aid in porting from Qt 2. It expanded on Qt 2's QValueList and added QValueVector, with our current understanding of what a vector is. Like QValueList, it was reference-counted. Most of us still remember, Qt 4.0, which was packaged 24-June-2005 (date of the files inside the tarball). There was even a dance about it... Qt 3's QPtrList, QPtrVector (that is, Qt 1's QList and QVector) as well as QValueList and QValueVector became Q3PtrList, Q3PtrVector, Q3ValueList and Q3ValueVector. A new implementation was provided for QList, QVector and QByteArray, in the forms that we have today. QCString became Q3CString, deriving from Q3MemArray, deriving from Q3GArray. QBitArray moved to having a QByteArray member instead of deriving from it. Qt 5 dropped the Qt 1 code and introduced QArrayData, QTypedArrayData, QArrayDataPointer and QArrayDataOps, but time ran out before we could properly make use of them. QADP and QADO are unused in the main version; I'm using them in my branch in a class called QGenericArray (a base class of QVector). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Tue Mar 21 06:27:44 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 21 Mar 2017 06:27:44 +0100 Subject: [Development] QList In-Reply-To: References: <201703202358.06763.marc.mutz@kdab.com> Message-ID: <201703210627.45201.marc.mutz@kdab.com> On Tuesday 21 March 2017 01:53:46 Kevin Kofler wrote: > Marc Mutz wrote: > > On Monday 20 March 2017 23:48:14 Kevin Kofler wrote: > >> Advantages: > >> > >> - code that needs QArrayList because it assumes stability of references > >> > >> could move to it right now, including the examples you keep bringing > >> up every so often. So it would allow fixing bugs now rather than in > >> Qt 6. > > > > What example? > > The ones you kept claiming I volunteered to fix. (I did not.) Ah, QToolBoxPrivate::PageList? You think you need QArrayList-as-a-class for that? The answer is no: https://codereview.qt-project.org/188941 Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From lars.knoll at qt.io Tue Mar 21 08:37:08 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 21 Mar 2017 07:37:08 +0000 Subject: [Development] QList In-Reply-To: <1797438.My2pJYudm9@tjmaciei-mobl1> References: <3222957.Av71qoJJfk@tjmaciei-mobl1> <1797438.My2pJYudm9@tjmaciei-mobl1> Message-ID: <0FAB91B8-564A-45D2-9A17-D1126EB4EFFD@qt.io> Yes, as Thiago nicely points out there is a long history. But using QList as the name for something that we’d nowadays would call an array for Qt 4.0 is something that was indeed somewhat inspired by Java. We were looking a lot at the APIs provided in other languages (Java being the closest one to C++), as we weren’t always happy with what the C++ standard provided. But I’d propose we don’t dig through the past too much, the decisions done then are nothing we can change anymore ;-) Cheers, Lars > On 21 Mar 2017, at 04:57, Thiago Macieira wrote: > > Em segunda-feira, 20 de março de 2017, às 17:45:53 PDT, Kevin Kofler escreveu: >> This assumption was already not true with Java 1.2, released December 8, >> 1998. That release introduced java.util.List as a generic interface to ANY >> list, including ArrayList. QList was introduced with Qt 4, released June 28, >> 2005. So it is unfair to blame Qt for not following the obsolete >> terminology you mention. > > You're forgetting Qt before 4.0. The current QList was introduced with Qt 4, > but previous versions had QList too. > > I can't find the exact release date for 1.0, but it happened some time after > 20-May-1995 (0.90) . > > Qt 1.x still supported compilers without template support (they were common in > the early to mid 90s). If you had templates, then QList was a #define to > QListT, which derived from QGList ("g" for generic), which was a doubly-linked > list of pointers to the item in question. It had virtuals too. That is > actually very similar to java.util.List... > > Qt 1.x also had a QVector (again, also provided as macro), deriving from > QGVector, which was a pointer vector. > > Confusingly, what we now call "vector" was implemented by QArray, which > derived from QGArray. QGArray managed only the byte-level array and QArray did > the necessary casting to the element type, as well as multiplications and > divisions by the element size. Unlike QList and QVector, QArray was reference- > counted. > > QByteArray was typedef'ed to QArray. QString derived from QByteArray > but still operated on arbitrary encoding. QBitArray derived from QByteArray. > There were also QStrList and QStrVec, which respectively derived from > QList and QVector. > > Qt 2.0 was released on 25-May-1999. Aside from removing support for compilers > that didn't support templates, QList, QVector and QArray remained the same. It > introduced QValueList, a doubly-linked list of values (not pointers). Like > QArray, it was reference-counted. QString was converted to UTF-16 and the old > Qt 1 QString became QCString (still deriving from QByteArray). Because of the > conversion, QStrList and QStrVec no longer worked with QString, so QStringList > was introduced, a specialisation of QValueList. > > Qt 3.0 was released 11-Oct-2001. Qt 2's QList and QVector were renamed to > QPtrList and QPtrVector, while QArray became QMemArray. All three headers had > a "compat" macro that would #define the old names, to aid in porting from Qt 2. > It expanded on Qt 2's QValueList and added QValueVector, with our current > understanding of what a vector is. Like QValueList, it was reference-counted. > > Most of us still remember, Qt 4.0, which was packaged 24-June-2005 (date of > the files inside the tarball). There was even a dance about it... > > Qt 3's QPtrList, QPtrVector (that is, Qt 1's QList and QVector) as well as > QValueList and QValueVector became Q3PtrList, Q3PtrVector, Q3ValueList and > Q3ValueVector. A new implementation was provided for QList, QVector and > QByteArray, in the forms that we have today. QCString became Q3CString, > deriving from Q3MemArray, deriving from Q3GArray. QBitArray moved to having a > QByteArray member instead of deriving from it. > > Qt 5 dropped the Qt 1 code and introduced QArrayData, QTypedArrayData, > QArrayDataPointer and QArrayDataOps, but time ran out before we could properly > make use of them. QADP and QADO are unused in the main version; I'm using them > in my branch in a class called QGenericArray (a base class of QVector). > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kevin.kofler at chello.at Tue Mar 21 13:25:36 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 21 Mar 2017 13:25:36 +0100 Subject: [Development] QList References: <201703202358.06763.marc.mutz@kdab.com> <201703210627.45201.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > Ah, QToolBoxPrivate::PageList? > > You think you need QArrayList-as-a-class for that? > > The answer is no: https://codereview.qt-project.org/188941 So that code was already not broken. Kevin Kofler From andre at familiesomers.nl Tue Mar 21 13:22:31 2017 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Tue, 21 Mar 2017 13:22:31 +0100 Subject: [Development] QList In-Reply-To: References: <201703181051.07307.marc.mutz@kdab.com> <201703201841.00116.marc.mutz@kdab.com> Message-ID: <76dda1c4-848d-c4d5-8c9c-363be5279e7f@familiesomers.nl> Op 20/03/2017 om 23:43 schreef Kevin Kofler: > Marc Mutz wrote: >> https://github.com/KDE/libkleo/blob/2fe48b77ba61fada80eaace8cb71dd0fd13265ae/src/kleo/stl_util.h > Thanks for proving my point that the STL APIs require tons of copy&paste > boilerplate in every project. > > That's not just your point, it's Stephanovs point as well. The STL is a starting point, a good, well-tested set of basic building blocks. Nobody claimed it contains any and all containers or algoritms you'd ever need. In fact, in its first form it contained more, but large parts of it got backed out before standardization. Surely you don't expect Qt to supply every container type and every algorithm possible? André From olivier at woboq.com Tue Mar 21 15:06:33 2017 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 21 Mar 2017 15:06:33 +0100 Subject: [Development] Diff between Qt-5.7.1 and Qt-5.8.0 on Android - Pointer Below the Cursor at Text Fields In-Reply-To: References: Message-ID: <1552611.dLdHt7iLM9@maurice> On Sonntag, 19. März 2017 09:39:57 CET Robert Iakobashvili wrote: > Hi, > Sorry for cross-posting, but maybe Qt Android maintainer is knowledgeable > about the issue below. > > Nexus-7 with Android-6 > > The same Qt app built with 5.7.1 works properly > and with 5.8.0 appears a blue pointer down the cursor at text fields > (QTextEdit, QTextLine) > > The pointer is buggy and doesn't follow the cursor properly when positioning > and re-positioning child-windows/popups. How buggy? Please report a bug on https://bugreports.qt.io I wonder if it's a bug with Android handles or with the widgets themself not reporting the proper cursor position. To be honest, i never tried widgets on a platform that have cursor handles. > How to get rid from it? Unfortunately there is no way. Maybe a input method hint should be added for it? > Were it some theme changes or something else from 5.7 to 5.8? > Thanks Yes, support for selection handle was added. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From thiago.macieira at intel.com Tue Mar 21 16:55:22 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 21 Mar 2017 08:55:22 -0700 Subject: [Development] QList In-Reply-To: <76dda1c4-848d-c4d5-8c9c-363be5279e7f@familiesomers.nl> References: <76dda1c4-848d-c4d5-8c9c-363be5279e7f@familiesomers.nl> Message-ID: <1832779.YtsljQEMGp@tjmaciei-mobl1> Em terça-feira, 21 de março de 2017, às 05:22:31 PDT, André Somers escreveu: > Op 20/03/2017 om 23:43 schreef Kevin Kofler: > > Marc Mutz wrote: > >> https://github.com/KDE/libkleo/blob/2fe48b77ba61fada80eaace8cb71dd0fd1326 > >> 5ae/src/kleo/stl_util.h> > > Thanks for proving my point that the STL APIs require tons of copy&paste > > boilerplate in every project. > > That's not just your point, it's Stephanovs point as well. The STL is a > starting point, a good, well-tested set of basic building blocks. Nobody > claimed it contains any and all containers or algoritms you'd ever need. > In fact, in its first form it contained more, but large parts of it got > backed out before standardization. Surely you don't expect Qt to supply > every container type and every algorithm possible? Not all, but a good set of algorithms that are in common use. Getting all keys and values is common, even if sometimes you leading to bad code. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andre at familiesomers.nl Wed Mar 22 06:49:42 2017 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Wed, 22 Mar 2017 06:49:42 +0100 Subject: [Development] QList In-Reply-To: <1832779.YtsljQEMGp@tjmaciei-mobl1> References: <76dda1c4-848d-c4d5-8c9c-363be5279e7f@familiesomers.nl> <1832779.YtsljQEMGp@tjmaciei-mobl1> Message-ID: <81bbc1d4-b08c-e0b8-8439-ffa398602f4d@familiesomers.nl> Op 21/03/2017 om 16:55 schreef Thiago Macieira: > Em terça-feira, 21 de março de 2017, às 05:22:31 PDT, André Somers escreveu: >> Op 20/03/2017 om 23:43 schreef Kevin Kofler: >>> Marc Mutz wrote: >>>> https://github.com/KDE/libkleo/blob/2fe48b77ba61fada80eaace8cb71dd0fd1326 >>>> 5ae/src/kleo/stl_util.h> >>> Thanks for proving my point that the STL APIs require tons of copy&paste >>> boilerplate in every project. >> That's not just your point, it's Stephanovs point as well. The STL is a >> starting point, a good, well-tested set of basic building blocks. Nobody >> claimed it contains any and all containers or algoritms you'd ever need. >> In fact, in its first form it contained more, but large parts of it got >> backed out before standardization. Surely you don't expect Qt to supply >> every container type and every algorithm possible? > Not all, but a good set of algorithms that are in common use. Getting all keys > and values is common, even if sometimes you leading to bad code. > Don't we have keyBegin and keyEnd for getting the keys? (No direct equivalent for values, it seems...): QVector keys; keys.reserve(theHash.size()); std::copy(theHash.keyBegin(), theHash.keyEnd(), std::back_inserter(keys)); Sure, it is longer than auto keys = theHash.keys(); but it does not bind you to using a container selected by Qt to return the keys in. If you need them in a vector, you can put them in a vector. If you want them in a set, you can put them in a set. André From thiago.macieira at intel.com Wed Mar 22 07:37:27 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 21 Mar 2017 23:37:27 -0700 Subject: [Development] QList In-Reply-To: <4326289.GUNhFrUgHh@tjmaciei-mobl1> References: <201703182233.32675.marc.mutz@kdab.com> <4326289.GUNhFrUgHh@tjmaciei-mobl1> Message-ID: <2884720.dci7Rcneo1@tjmaciei-mobl1> Em domingo, 19 de março de 2017, às 11:44:44 PDT, Thiago Macieira escreveu: > On sábado, 18 de março de 2017 14:33:32 PDT Marc Mutz wrote: > > On Saturday 18 March 2017 19:30:35 Thiago Macieira wrote: > > > class QStringView - has all the const functions > > > class QString : public QStringView - adds the mutating functions > > > class QtExclusive::QString : public QString > > > > No inheritance. These things have no is-a relationship whatsoever. > > Right, I came to the same conclusion in the shower after posting this and > then forgot to post once I was out. Ok, here's another shower idea. Instead of the above, we use a seldom used technique: private inheritance. class QStringView class QString : private QStringView class QtExclusive::QString : private QString Both QString and QtExclusive::QString would do a lot of: using QStringView::indexOf; using QStringView::contains; using QStringView::startsWith; using QStringView::endsWith; plus: QString trimmed() &&; QString trimmed() const &; etc. In fact, most of the mutating functions in the exclusive class can be *exactly* the reference-counted version, as the reference count will be 1, so the detach() will do nothing. The private inheritance solves this problem: > My problem was the exclusive kind, because you could then do: > > QtExclusive::QString es; > QString &s = es; > s = somethingElse(); > // es could now be sharing, which is a violation The second line above would fail to compile. At the same time, any changes to QStringView almost auomatically propagate to the other two classes. And almost all changes to QString go to QtExclusive::QString without even having to do anything. Another thing I'd want is for QStringView to carry the pointer to the QArrayData like QString does. In the regular QStringView uses, it would be null. This has the drawback that QStringView would now be passed by implicit reference instead of by value in registers (though, as we discovered, Windows 64-bit already does this). The reason I'd want this is for two use-cases: 1) when you create a QStringView from a QString (but not from QtExclusive::QString), it would carry the original string's QArrayData pointer. That's ok because if the pointer to the data is valid, the pointer to the allocation block is too. But when if you later did: m_string = sv; the new QString would resume reference counting from the original QString, without actually creating a copy. 2) for SSO: on little-endian machines, we need the first byte to have bit 0 set. The first byte is in the base class, so QStringView needs to start with that pointer. For QStringView we could alternatively also the bit 0 in the data begin pointer, but that technique would not work for QByteArrayView. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Mar 22 07:43:04 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 21 Mar 2017 23:43:04 -0700 Subject: [Development] QList In-Reply-To: <81bbc1d4-b08c-e0b8-8439-ffa398602f4d@familiesomers.nl> References: <1832779.YtsljQEMGp@tjmaciei-mobl1> <81bbc1d4-b08c-e0b8-8439-ffa398602f4d@familiesomers.nl> Message-ID: <3037349.HnfHOzd1Lv@tjmaciei-mobl1> Em terça-feira, 21 de março de 2017, às 22:49:42 PDT, André Somers escreveu: > QVector keys; > keys.reserve(theHash.size()); > std::copy(theHash.keyBegin(), theHash.keyEnd(), std::back_inserter(keys)); > > Sure, it is longer than > auto keys = theHash.keys(); The whole issue here is the "sure it is longer". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Martin.Smith at qt.io Wed Mar 22 08:39:03 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Wed, 22 Mar 2017 07:39:03 +0000 Subject: [Development] QList In-Reply-To: <3037349.HnfHOzd1Lv@tjmaciei-mobl1> References: <1832779.YtsljQEMGp@tjmaciei-mobl1> <81bbc1d4-b08c-e0b8-8439-ffa398602f4d@familiesomers.nl>, <3037349.HnfHOzd1Lv@tjmaciei-mobl1> Message-ID: >The whole issue here is the "sure it is longer". It's not the WHOLE issue. If you encounter... auto keys = theHash.keys(); ...in someone's code, you have to look around in the rest of the code to figure out what keys is, unless you are already familiar with the keys() function for whatever theHash is. ________________________________ From: Development on behalf of Thiago Macieira Sent: Wednesday, March 22, 2017 7:43:04 AM To: development at qt-project.org Subject: Re: [Development] QList Em terça-feira, 21 de março de 2017, às 22:49:42 PDT, André Somers escreveu: > QVector keys; > keys.reserve(theHash.size()); > std::copy(theHash.keyBegin(), theHash.keyEnd(), std::back_inserter(keys)); > > Sure, it is longer than > auto keys = theHash.keys(); The whole issue here is the "sure it is longer". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From evilruff at gmail.com Wed Mar 22 09:04:52 2017 From: evilruff at gmail.com (evilruff at gmail.com) Date: Wed, 22 Mar 2017 11:04:52 +0300 Subject: [Development] QList In-Reply-To: References: <1832779.YtsljQEMGp@tjmaciei-mobl1> <81bbc1d4-b08c-e0b8-8439-ffa398602f4d@familiesomers.nl> <3037349.HnfHOzd1Lv@tjmaciei-mobl1> Message-ID: <0C03224E-3A38-4633-A79D-DE15884A2E0F@gmail.com> > On 22 Mar 2017, at 10:39, Martin Smith wrote: > > >The whole issue here is the "sure it is longer". > > It's not the WHOLE issue. If you encounter... > > auto keys = theHash.keys(); > > ...in someone's code, you have to look around in the rest of the code to figure out what keys is, unless you are already familiar with the keys() function for whatever theHash is. Totally agree. That’s why I never use auto's myself as then you work on many different projects after several years in complicated code you hardly remember what those ‘auto’s’ means. I mean I am not against them in general, but as for me I prefer to have an explicit typing in my code, it’s much easier to read. As for QList/QVector.. With all respect to what’s already was saying in this thread, issues mentioned in original article about Qt containers are known for years and it’s more about to choose right container, I really don’t see a point why should I change something if I know exactly how my code works and why I use one or another container. As an example I have one project which is already about 15-17 years old..it’s big commercial product. It started with Qt3, then was at some point moved by somebody to Qt4 with Qt3Support.. then I got back to it we started to migrate it to Qt5, it took almost half a year for me to migrate it to stable version. I am not even talking about a fact that last year I hardly can answer myself which 5.* is a production version, but that’s other subject. So I really think that removing/changing behaviour of such core things like QList is really a bad idea. It’s not about laziness.. it’s more about that the ones who understand difference between QVector/QList etc already using them right, and for others it doest really matter.. Yuri -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Wed Mar 22 09:27:54 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 22 Mar 2017 09:27:54 +0100 Subject: [Development] QList In-Reply-To: <2884720.dci7Rcneo1@tjmaciei-mobl1> References: <4326289.GUNhFrUgHh@tjmaciei-mobl1> <2884720.dci7Rcneo1@tjmaciei-mobl1> Message-ID: <201703220927.55011.marc.mutz@kdab.com> On Wednesday 22 March 2017 07:37:27 Thiago Macieira wrote: > Another thing I'd want is for QStringView to carry the pointer to the > QArrayData like QString does. NAK to inheriting from QStringView, publicly or privately. NAK to adding another pointer. If you need a base class for your Q6String, use QStringRef. It's already got what you want: tight coupling with QString. QStringView will not be that base class. QStringView will model whatever std::string_view models. Anything that pessimises QStringView as a wrapper around a char16_t literal is not acceptable. I understand that you sit on a pile of finished changes to QString just waiting for Qt 6 to come around. And I welcome it (I think, we'll see when you upload some of it to Gerrit). But leave QStringView out of it. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From edward.welbourne at qt.io Wed Mar 22 10:36:19 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 22 Mar 2017 09:36:19 +0000 Subject: [Development] QList In-Reply-To: <201703220927.55011.marc.mutz@kdab.com> References: <4326289.GUNhFrUgHh@tjmaciei-mobl1> <2884720.dci7Rcneo1@tjmaciei-mobl1>, <201703220927.55011.marc.mutz@kdab.com> Message-ID: On Wednesday 22 March 2017 07:37:27 Thiago Macieira wrote: >> Another thing I'd want is for QStringView to carry the pointer to the >> QArrayData like QString does. Marc Mutz (22 March 2017 09:27) > NAK to inheriting from QStringView, publicly or privately. NAK to > adding another pointer. Is there scope for a common (perhaps private) base, to be used by (at least) QString and QStringView, something along the lines of a Java interface ? It needn't actually be pure virtual, if we can chose the right factoring of what's different between the assorted strings, so don't be too slavish in following Java's interfaces. They all package string data and they share many methods in common, many of which can share (indeed, at present, *do* share, as static functions) implementation. The design of string classes always amuses me: every text-book on object-oriented design (that I've seen) launches into it as an example and *all* of them give results that I wouldn't want to use in production code. The problem turns out to be *hard* because we do such a lot with strings; and allocation *isn't* a negligible cost. Much of what's hard about it is subtle: I've yet to see a string class I thought was Good. Good luck in your efforts to break that pattern ;^> Eddy. From marc.mutz at kdab.com Wed Mar 22 11:22:37 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 22 Mar 2017 11:22:37 +0100 Subject: [Development] QList In-Reply-To: References: <4326289.GUNhFrUgHh@tjmaciei-mobl1> <2884720.dci7Rcneo1@tjmaciei-mobl1>, <201703220927.55011.marc.mutz@kdab.com> Message-ID: On 2017-03-22 10:36, Edward Welbourne wrote: > On Wednesday 22 March 2017 07:37:27 Thiago Macieira wrote: >>> Another thing I'd want is for QStringView to carry the pointer to the >>> QArrayData like QString does. > > Marc Mutz (22 March 2017 09:27) >> NAK to inheriting from QStringView, publicly or privately. NAK to >> adding another pointer. > > Is there scope for a common (perhaps private) base, to be used by (at > least) QString and QStringView, something along the lines of a Java > interface ? No. Sharing of functionality is best done with free functions. That makes the functionality available to the user independent of any particular class, and allows code sharing by templates, too, across, say QPoint and QPointF. Or QString and QByteArray. Or QStringView and QLatin1String and QUtf8String... > The design of string classes always amuses me: every text-book on > object-oriented design (that I've seen) launches into it as an example > and *all* of them give results that I wouldn't want to use in > production > code. The problem turns out to be *hard* because we do such a lot with > strings; and allocation *isn't* a negligible cost. Much of what's hard > about it is subtle: I've yet to see a string class I thought was Good. > Good luck in your efforts to break that pattern ;^> If you mentally remove all the complexity caused by CoW and by not having QStringView and QUtf8String, then QString comes pretty close. I'd remove split() and toHtmlEscaped(), replacing them with a QStringTokenizer and qToHtmlEscaped(), but otherwise, it's the best I've seen so far. Thanks, Marc From philwave at gmail.com Wed Mar 22 12:03:55 2017 From: philwave at gmail.com (Philippe) Date: Wed, 22 Mar 2017 12:03:55 +0100 Subject: [Development] QList In-Reply-To: References: Message-ID: <20170322120354.8CFE.6F0322A@gmail.com> Externalizing sharing brings more flexibility indeed, but at the price of more complexity on the user side, ie. less convenience... Philippe On Wed, 22 Mar 2017 11:22:37 +0100 Marc Mutz wrote: > On 2017-03-22 10:36, Edward Welbourne wrote: > > On Wednesday 22 March 2017 07:37:27 Thiago Macieira wrote: > >>> Another thing I'd want is for QStringView to carry the pointer to the > >>> QArrayData like QString does. > > > Marc Mutz (22 March 2017 09:27) > >> NAK to inheriting from QStringView, publicly or privately. NAK to > >> adding another pointer. > > > Is there scope for a common (perhaps private) base, to be used by (at > > least) QString and QStringView, something along the lines of a Java > > interface ? > > No. Sharing of functionality is best done with free functions. That makes the functionality available to the user independent of any particular class, and allows code sharing by templates, too, across, say QPoint and QPointF. Or QString and QByteArray. Or QStringView and QLatin1String and QUtf8String... > > > The design of string classes always amuses me: every text-book on > > object-oriented design (that I've seen) launches into it as an example > > and *all* of them give results that I wouldn't want to use in > production > > code. The problem turns out to be *hard* because we do such a lot with > > strings; and allocation *isn't* a negligible cost. Much of what's hard > > about it is subtle: I've yet to see a string class I thought was Good. > > Good luck in your efforts to break that pattern ;^> > > If you mentally remove all the complexity caused by CoW and by not having QStringView and QUtf8String, then QString comes pretty close. I'd remove split() and toHtmlEscaped(), replacing them with a QStringTokenizer and qToHtmlEscaped(), but otherwise, it's the best I've seen so far. > > Thanks, > Marc > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From ville.voutilainen at gmail.com Wed Mar 22 12:08:19 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 22 Mar 2017 13:08:19 +0200 Subject: [Development] QList In-Reply-To: <20170322120354.8CFE.6F0322A@gmail.com> References: <20170322120354.8CFE.6F0322A@gmail.com> Message-ID: On 22 March 2017 at 13:03, Philippe wrote: > Externalizing sharing brings more flexibility indeed, but at the price > of more complexity on the user side, ie. less convenience... Whether the sharing is done in a private base or via free functions is not visible to the user. From philwave at gmail.com Wed Mar 22 12:14:49 2017 From: philwave at gmail.com (Philippe) Date: Wed, 22 Mar 2017 12:14:49 +0100 Subject: [Development] QList In-Reply-To: References: <20170322120354.8CFE.6F0322A@gmail.com> Message-ID: <20170322121448.8D02.6F0322A@gmail.com> by user, I meant "application programmer using Qt" :) Philippe On Wed, 22 Mar 2017 13:08:19 +0200 Ville Voutilainen wrote: > On 22 March 2017 at 13:03, Philippe wrote: > > Externalizing sharing brings more flexibility indeed, but at the price > > of more complexity on the user side, ie. less convenience... > > Whether the sharing is done in a private base or via free functions is > not visible to the user. From ville.voutilainen at gmail.com Wed Mar 22 12:51:11 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 22 Mar 2017 13:51:11 +0200 Subject: [Development] QList In-Reply-To: <20170322121448.8D02.6F0322A@gmail.com> References: <20170322120354.8CFE.6F0322A@gmail.com> <20170322121448.8D02.6F0322A@gmail.com> Message-ID: On 22 March 2017 at 13:14, Philippe wrote: > by user, I meant "application programmer using Qt" :) So did I. :) The question for a free utility function and a base class is the same: are they exposed in any way? If not, neither of them is something the application programmer cares about, and thus there's no increased complexity nor less convenience for the application programmer. From michael.winkelmann at qt.io Wed Mar 22 15:28:00 2017 From: michael.winkelmann at qt.io (Michael Winkelmann) Date: Wed, 22 Mar 2017 15:28:00 +0100 Subject: [Development] QList In-Reply-To: <7341375.cH6AiziBB6@tjmaciei-mobl1> References: <201703181837.16139.marc.mutz@kdab.com> <7341375.cH6AiziBB6@tjmaciei-mobl1> Message-ID: <7012a545-4890-3037-fc20-97806cc9bc4f@qt.io> Does that mean that QList would simply be a C++11 template alias for QVector? On 18.03.2017 19:15, Thiago Macieira wrote: > But as time went by, I don't think that hybrid approach is valid. A vector is > simply much better. For Qt 6, I'd like QVector and QList to be the same type > -- possibly even interchangeable, so that code that began using QVector in > Qt 5 will be able to "return" QList. -- --- Michael Winkelmann Qt Advisor The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin michael.winkelmann at qt.io +4915122973404 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B --- From giuseppe.dangelo at kdab.com Wed Mar 22 15:42:29 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Wed, 22 Mar 2017 15:42:29 +0100 Subject: [Development] QList In-Reply-To: <7012a545-4890-3037-fc20-97806cc9bc4f@qt.io> References: <201703181837.16139.marc.mutz@kdab.com> <7341375.cH6AiziBB6@tjmaciei-mobl1> <7012a545-4890-3037-fc20-97806cc9bc4f@qt.io> Message-ID: <53a25387-5372-2942-327f-af8180d772cf@kdab.com> Il 22/03/2017 15:28, Michael Winkelmann ha scritto: > Does that mean that QList would simply be a C++11 template alias for > QVector? That's one option on the table, I guess. On one side, it's simple to implement, on the other side, requires fixing all the code that was overloaded on QVector and QList, special-cased one of the two instead of the other (hello, QML engine), and so on. Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From coroberti at gmail.com Thu Mar 23 07:02:58 2017 From: coroberti at gmail.com (Robert Iakobashvili) Date: Thu, 23 Mar 2017 08:02:58 +0200 Subject: [Development] Diff between Qt-5.7.1 and Qt-5.8.0 on Android - Pointer Below the Cursor at Text Fields In-Reply-To: <1552611.dLdHt7iLM9@maurice> References: <1552611.dLdHt7iLM9@maurice> Message-ID: On Tue, Mar 21, 2017 at 4:06 PM, Olivier Goffart wrote: > On Sonntag, 19. März 2017 09:39:57 CET Robert Iakobashvili wrote: > > Nexus-7 with Android-6 > > The same Qt app built with 5.7.1 works properly > > and with 5.8.0 appears a blue pointer down the cursor at text fields > > (QTextEdit, QTextLine) > > > > The pointer is buggy and doesn't follow the cursor properly when > positioning > > and re-positioning child-windows/popups. > How buggy? Please report a bug on https://bugreports.qt.io > I wonder if it's a bug with Android handles or with the widgets themself > not > reporting the proper cursor position. > To be honest, i never tried widgets on a platform that have cursor handles. > > > How to get rid from it? > Unfortunately there is no way. > Maybe a input method hint should be added for it? > > > Were it some theme changes or something else from 5.7 to 5.8? > > Thanks > Yes, support for selection handle was added. > > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - > https://code.woboq.org > > Dear Olivier, Thank you for your kind reply so far the only one. The pointer by itself is looking bad and detracts attention from the writing done even if it is positioned properly. Definitely, it should be arranged options: - to get rid from the pointer (handles) completely; - to change the image of the pointer like small image, NULL image, etc. To reproduce the disastrous look, one can use example of textedit in richedits, widgets. I will try to come with my minimal example to reproduce the issue with child widgets positioning and re-positioning over the parents and file it via the bug reporting system. Who is the maintainer today for the Qt-Android port? Thank you. Kind regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Thu Mar 23 08:32:14 2017 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 23 Mar 2017 08:32:14 +0100 Subject: [Development] RFC: Containers member functions for algorithm Message-ID: <18416166.MC6PJ1Ml06@maurice> Hi everyone, I have been wondering if we should enhance Qt container with member functions to help using some of the standard algorithm. a peace of code is better than many words. We would be able to do: myList.sort(); //or myList.sort([](auto &a, auto &b){ return a.member < b.member; }); if (myList.contains([&value](const auto &elem){ return elem.id == value; })) doSomething(); myList.removeIf([&](const auto &elem) { elem.field > someValue; }) And these are a tad more convenient than using the standard library directly. Compare to: myList.erase(std::remove_if(myList.begin(), myList.end(), [&](const auto &elem) { elem.field > someValue; }), myList.end()); Of course, myList can be a QList, a QVector, or a QVarLenghtArray Here is an overview in how this could be implemented, should we want this: https://codereview.qt-project.org/#/c/189313/ Anyway, before I continue working on this patch, I want to know if this is even something what the Qt Project wants. The reason we would want it are obvious: convenience. In the mean time, the standard is working on the so called range library. So in C++20, you could maybe just write std::sort(myList). But that's in the far future, and I want to be able to use it now. There are already convenient range libraries that makes things convenient available on github, but that's another dependency and the compatibility guarantee are not the same. The reason we would not want this is because this makes our containers too convenient. The implementation of QVector is inferior to the one of std::vector. (for example, it cannot contains move-only types). Right now, it is quite easy to replace QVector by std::vector. But adding nice feature to QVector may mean a reason to keep QVector longer in Qt6 instead of changing to standard containers. Marc already expressed his opinion on the gerrit change, pointing out that we deprecated qSort and the qt algorithm for a reason: the quality of the std algorithm was better than the naive implementation in Qt. However this is just a helper around the std algorithm implementation. Why did we not added these function already in Qt 4.0? I was not there yet, but I believe this might have been for technical reason: MSVC 6 was still supported until Qt 4.5, which mans no template member functions. Also sort needs an operator<, and non-template function might be instantiated even if not used. So with this mail I would like to know what you think. If you think this is a good idea or a terrible one. Once we agreed the general idea is good, we can go into the details of the API or implementation. On this WIP patch, I only took the algorithm that were most used within Qt and QtCreator. I realize that QtCreator already has helper functions: https://code.woboq.org/qt5/qt-creator/src/libs/utils/algorithm.h.html That's I think one proof that shows that this would be useful. I am wondering if findIf shoud return a pointer or an iterator. Returning a pointer allow things like if (auto *elem = myContainer.findIf([&](const auto &elem) { return elem.foo == bar; })) elem->plop = myPlop; But does not work well if you want to find-then-remove: auto it = std::find(myContainer.begin(), myContainer.end(), [&](const auto &elem) { return elem.foo == bar; }); if (it != myContainer.end()) { myResult = *it; myContainer.erase(it); // not possible if 'it' was a pointer } So I'm afraid there will be much discussions and bike-shedding Regards -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From Simon.Hausmann at qt.io Thu Mar 23 09:26:15 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 23 Mar 2017 08:26:15 +0000 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: <18416166.MC6PJ1Ml06@maurice> References: <18416166.MC6PJ1Ml06@maurice> Message-ID: Hi, I love this idea and how it goes into the direction of making life easier (more convenient) for developers. Simon > On 23 Mar 2017, at 08:32, Olivier Goffart wrote: > > Hi everyone, > > I have been wondering if we should enhance Qt container with member functions > to help using some of the standard algorithm. > a peace of code is better than many words. We would be able to do: > > myList.sort(); > //or > myList.sort([](auto &a, auto &b){ return a.member < b.member; }); > > if (myList.contains([&value](const auto &elem){ return elem.id == value; })) > doSomething(); > > myList.removeIf([&](const auto &elem) { elem.field > someValue; }) > > > And these are a tad more convenient than using the standard library directly. > Compare to: > myList.erase(std::remove_if(myList.begin(), myList.end(), > [&](const auto &elem) { elem.field > someValue; }), > myList.end()); > > Of course, myList can be a QList, a QVector, or a QVarLenghtArray > > Here is an overview in how this could be implemented, should we want this: > https://codereview.qt-project.org/#/c/189313/ > > > Anyway, before I continue working on this patch, I want to know if this is > even something what the Qt Project wants. > > The reason we would want it are obvious: convenience. > > In the mean time, the standard is working on the so called range library. So > in C++20, you could maybe just write std::sort(myList). > But that's in the far future, and I want to be able to use it now. > There are already convenient range libraries that makes things convenient > available on github, but that's another dependency and the compatibility > guarantee are not the same. > > > The reason we would not want this is because this makes our containers too > convenient. The implementation of QVector is inferior to the one of > std::vector. (for example, it cannot contains move-only types). > Right now, it is quite easy to replace QVector by std::vector. But adding nice > feature to QVector may mean a reason to keep QVector longer in Qt6 instead of > changing to standard containers. > > Marc already expressed his opinion on the gerrit change, pointing out that we > deprecated qSort and the qt algorithm for a reason: the quality of the std > algorithm was better than the naive implementation in Qt. However this is just > a helper around the std algorithm implementation. > > > Why did we not added these function already in Qt 4.0? I was not there yet, > but I believe this might have been for technical reason: MSVC 6 was still > supported until Qt 4.5, which mans no template member functions. > Also sort needs an operator<, and non-template function might be instantiated > even if not used. > > So with this mail I would like to know what you think. If you think this is a > good idea or a terrible one. > > > Once we agreed the general idea is good, we can go into the details of the API > or implementation. > > On this WIP patch, I only took the algorithm that were most used within Qt and > QtCreator. I realize that QtCreator already has helper functions: > https://code.woboq.org/qt5/qt-creator/src/libs/utils/algorithm.h.html > That's I think one proof that shows that this would be useful. > > I am wondering if findIf shoud return a pointer or an iterator. > Returning a pointer allow things like > if (auto *elem = myContainer.findIf([&](const auto &elem) > { return elem.foo == bar; })) > elem->plop = myPlop; > > But does not work well if you want to find-then-remove: > auto it = std::find(myContainer.begin(), myContainer.end(), > [&](const auto &elem) { return elem.foo == bar; }); > if (it != myContainer.end()) { > myResult = *it; > myContainer.erase(it); // not possible if 'it' was a pointer > } > > So I'm afraid there will be much discussions and bike-shedding > > Regards > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - https://code.woboq.org > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Eike.Ziller at qt.io Thu Mar 23 09:27:53 2017 From: Eike.Ziller at qt.io (Eike Ziller) Date: Thu, 23 Mar 2017 08:27:53 +0000 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: <18416166.MC6PJ1Ml06@maurice> References: <18416166.MC6PJ1Ml06@maurice> Message-ID: > On Mar 23, 2017, at 8:32 AM, Olivier Goffart wrote: > > Hi everyone, > > I have been wondering if we should enhance Qt container with member functions > to help using some of the standard algorithm. > a peace of code is better than many words. We would be able to do: > > myList.sort(); > //or > myList.sort([](auto &a, auto &b){ return a.member < b.member; }); > > if (myList.contains([&value](const auto &elem){ return elem.id == value; })) > doSomething(); > > myList.removeIf([&](const auto &elem) { elem.field > someValue; }) > > > And these are a tad more convenient than using the standard library directly. > Compare to: > myList.erase(std::remove_if(myList.begin(), myList.end(), > [&](const auto &elem) { elem.field > someValue; }), > myList.end()); > > Of course, myList can be a QList, a QVector, or a QVarLenghtArray > > Here is an overview in how this could be implemented, should we want this: > https://codereview.qt-project.org/#/c/189313/ > > > Anyway, before I continue working on this patch, I want to know if this is > even something what the Qt Project wants. > > The reason we would want it are obvious: convenience. > > In the mean time, the standard is working on the so called range library. So > in C++20, you could maybe just write std::sort(myList). > But that's in the far future, and I want to be able to use it now. > There are already convenient range libraries that makes things convenient > available on github, but that's another dependency and the compatibility > guarantee are not the same. > > > The reason we would not want this is because this makes our containers too > convenient. The implementation of QVector is inferior to the one of > std::vector. (for example, it cannot contains move-only types). > Right now, it is quite easy to replace QVector by std::vector. But adding nice > feature to QVector may mean a reason to keep QVector longer in Qt6 instead of > changing to standard containers. > > Marc already expressed his opinion on the gerrit change, pointing out that we > deprecated qSort and the qt algorithm for a reason: the quality of the std > algorithm was better than the naive implementation in Qt. However this is just > a helper around the std algorithm implementation. > > > Why did we not added these function already in Qt 4.0? I was not there yet, > but I believe this might have been for technical reason: MSVC 6 was still > supported until Qt 4.5, which mans no template member functions. > Also sort needs an operator<, and non-template function might be instantiated > even if not used. > > So with this mail I would like to know what you think. If you think this is a > good idea or a terrible one. > > > Once we agreed the general idea is good, we can go into the details of the API > or implementation. > > On this WIP patch, I only took the algorithm that were most used within Qt and > QtCreator. I realize that QtCreator already has helper functions: > https://code.woboq.org/qt5/qt-creator/src/libs/utils/algorithm.h.html > That's I think one proof that shows that this would be useful. I personally would not want to code without these anymore, and would be very glad if someone put similar things into Qt :) I do not think that these belong into the API of the containers though, or at least if (some of) this API gets into the containers itself, the implementation should just call generic functions. There is no reason why the convenience should be restricted to the Qt containers, why transforming a QVector should be convenient but not transforming a std::vector. Adding functions instead of API to the containers also avoids bloating the API of the containers, and makes the convenience completely optional. > I am wondering if findIf shoud return a pointer or an iterator. > Returning a pointer allow things like > if (auto *elem = myContainer.findIf([&](const auto &elem) > { return elem.foo == bar; })) > elem->plop = myPlop; > > But does not work well if you want to find-then-remove: > auto it = std::find(myContainer.begin(), myContainer.end(), > [&](const auto &elem) { return elem.foo == bar; }); > if (it != myContainer.end()) { > myResult = *it; > myContainer.erase(it); // not possible if 'it' was a pointer > } > > So I'm afraid there will be much discussions and bike-shedding Using functions instead of adding API to the containers has potential to greatly reduce the bike-shedding. Just add one function that returns a pointer, and another one that returns the iterator, without the fear of bloating the API of every container class. Br, Eike > Regards > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - https://code.woboq.org > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From marc.mutz at kdab.com Thu Mar 23 10:36:06 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 23 Mar 2017 10:36:06 +0100 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: References: <18416166.MC6PJ1Ml06@maurice> Message-ID: <201703231036.06944.marc.mutz@kdab.com> On Thursday 23 March 2017 09:27:53 Eike Ziller wrote: > I do not think that these belong into the API of the containers though, or > at least if (some of) this API gets into the containers itself, the > implementation should just call generic functions. There is no reason why > the convenience should be restricted to the Qt containers, why > transforming a QVector should be convenient but not transforming a > std::vector. Adding functions instead of API to the containers also avoids > bloating the API of the containers, and makes the convenience completely > optional. Exactly. Bring back qSort(Container &), calling std::sort(std::begin(c), std::end(c)). But leave the container interface alone. Everyone probably comes up with these (I posted mine in the QList thread: https://github.com/KDE/libkleo/blob/2fe48b77ba61fada80eaace8cb71dd0fd1326). That said, there's a reason why there's no std::sort(Container &). It's because you need Concepts to disambiguate the various overloads. Well, that and because Eric Niebler doesn't manage to limit the scope of his range proposals. Anyway, I gave my opinion, incl. technical reasons why using member functions for this is a bad idea on Gerrit. I only want to add two things I did not mention there: First, that one of the usual reasons given for preferring member functions over free functions, discoverability, is a tool problem, and should be solved in the tools. Include free functions in the .-completion and it no longer matters whether a function is a member or a free function. There're proposals floating around for years to make o.f() fall back to f(o) for std C++. Ville can probably say more about the status of these. This is a problem that can be solved now in QtCreator and doesn't require adding more API mistakes. Second, that member functions always get their *this argument passed by reference. A free function can take the argument by value instead. It probably doesn't matter much for inline methods. But Chandler has used this example in his compiler talks as an example where a seemingly innocuous change (free to member function) can make the compiler's job much harder, due to the involvement of memory. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From philwave at gmail.com Thu Mar 23 10:50:03 2017 From: philwave at gmail.com (Philippe) Date: Thu, 23 Mar 2017 10:50:03 +0100 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: <18416166.MC6PJ1Ml06@maurice> References: <18416166.MC6PJ1Ml06@maurice> Message-ID: <20170323105002.C645.6F0322A@gmail.com> I hardly imagine a "container" api without a "contains()" member. What I would call good sense. Qt already has this, std not. The other member that makes sense, if "indexOf()"... Qt already has this. For the rest, free functions provide more flexibility. >> I realize that QtCreator already has helper functions: >>https://code.woboq.org/qt5/qt-creator/src/libs/utils/algorithm.h.html Similar convenience wrappers are found in many applications... It would not harm to have such wrappers in Qt. Philippe On Thu, 23 Mar 2017 08:32:14 +0100 Olivier Goffart wrote: > Hi everyone, > > I have been wondering if we should enhance Qt container with member functions > to help using some of the standard algorithm. > a peace of code is better than many words. We would be able to do: > > myList.sort(); > //or > myList.sort([](auto &a, auto &b){ return a.member < b.member; }); > > if (myList.contains([&value](const auto &elem){ return elem.id == value; })) > doSomething(); > > myList.removeIf([&](const auto &elem) { elem.field > someValue; }) > > > And these are a tad more convenient than using the standard library directly. > Compare to: > myList.erase(std::remove_if(myList.begin(), myList.end(), > [&](const auto &elem) { elem.field > someValue; }), > myList.end()); > > Of course, myList can be a QList, a QVector, or a QVarLenghtArray > > Here is an overview in how this could be implemented, should we want this: > https://codereview.qt-project.org/#/c/189313/ > > > Anyway, before I continue working on this patch, I want to know if this is > even something what the Qt Project wants. > > The reason we would want it are obvious: convenience. > > In the mean time, the standard is working on the so called range library. So > in C++20, you could maybe just write std::sort(myList). > But that's in the far future, and I want to be able to use it now. > There are already convenient range libraries that makes things convenient > available on github, but that's another dependency and the compatibility > guarantee are not the same. > > > The reason we would not want this is because this makes our containers too > convenient. The implementation of QVector is inferior to the one of > std::vector. (for example, it cannot contains move-only types). > Right now, it is quite easy to replace QVector by std::vector. But adding nice > feature to QVector may mean a reason to keep QVector longer in Qt6 instead of > changing to standard containers. > > Marc already expressed his opinion on the gerrit change, pointing out that we > deprecated qSort and the qt algorithm for a reason: the quality of the std > algorithm was better than the naive implementation in Qt. However this is just > a helper around the std algorithm implementation. > > > Why did we not added these function already in Qt 4.0? I was not there yet, > but I believe this might have been for technical reason: MSVC 6 was still > supported until Qt 4.5, which mans no template member functions. > Also sort needs an operator<, and non-template function might be instantiated > even if not used. > > So with this mail I would like to know what you think. If you think this is a > good idea or a terrible one. > > > Once we agreed the general idea is good, we can go into the details of the API > or implementation. > > On this WIP patch, I only took the algorithm that were most used within Qt and > QtCreator. I realize that QtCreator already has helper functions: > https://code.woboq.org/qt5/qt-creator/src/libs/utils/algorithm.h.html > That's I think one proof that shows that this would be useful. > > I am wondering if findIf shoud return a pointer or an iterator. > Returning a pointer allow things like > if (auto *elem = myContainer.findIf([&](const auto &elem) > { return elem.foo == bar; })) > elem->plop = myPlop; > > But does not work well if you want to find-then-remove: > auto it = std::find(myContainer.begin(), myContainer.end(), > [&](const auto &elem) { return elem.foo == bar; }); > if (it != myContainer.end()) { > myResult = *it; > myContainer.erase(it); // not possible if 'it' was a pointer > } > > So I'm afraid there will be much discussions and bike-shedding > > Regards > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - https://code.woboq.org > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From ville.voutilainen at gmail.com Thu Mar 23 11:01:12 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Thu, 23 Mar 2017 12:01:12 +0200 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: <201703231036.06944.marc.mutz@kdab.com> References: <18416166.MC6PJ1Ml06@maurice> <201703231036.06944.marc.mutz@kdab.com> Message-ID: On 23 March 2017 at 11:36, Marc Mutz wrote: > That said, there's a reason why there's no std::sort(Container &). It's > because you need Concepts to disambiguate the various overloads. Well, that > and because Eric Niebler doesn't manage to limit the scope of his range > proposals. The TS proposal is quite tightly scoped. It doesn't have range views and range actions, for instance. > matters whether a function is a member or a free function. There're proposals > floating around for years to make o.f() fall back to f(o) for std C++. Ville > can probably say more about the status of these. This is a problem that can be That proposal was rejected, whether it will come back in some form is for the moment unknown. From marc.mutz at kdab.com Thu Mar 23 11:04:26 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 23 Mar 2017 11:04:26 +0100 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: References: <18416166.MC6PJ1Ml06@maurice> <201703231036.06944.marc.mutz@kdab.com> Message-ID: <67d128af1d53acf5b40146a69cff464e@kdab.com> On 2017-03-23 11:01, Ville Voutilainen wrote: > On 23 March 2017 at 11:36, Marc Mutz wrote: >> That said, there's a reason why there's no std::sort(Container &). >> It's >> because you need Concepts to disambiguate the various overloads. Well, >> that >> and because Eric Niebler doesn't manage to limit the scope of his >> range >> proposals. > > The TS proposal is quite tightly scoped. It doesn't have range views > and range actions, for instance. I was referring to the | overloading, in particular. Time to look at it once more, then. :) Thanks, Marc From giuseppe.dangelo at kdab.com Thu Mar 23 11:12:31 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 23 Mar 2017 11:12:31 +0100 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: <20170323105002.C645.6F0322A@gmail.com> References: <18416166.MC6PJ1Ml06@maurice> <20170323105002.C645.6F0322A@gmail.com> Message-ID: <779413ad-b998-4f09-9dc2-f97ee54845b8@kdab.com> Il 23/03/2017 10:50, Philippe ha scritto: > I hardly imagine a "container" api without a "contains()" member. What I > would call good sense. Qt already has this, std not. > > The other member that makes sense, if "indexOf()"... Qt already has this. Bikeshedding: this implies that your container contains a type comparable for equality, but no sequential container enforces that (nor it should), so this is effectively API pollution. Bikeshedding²: this also means more symbols exported (if you end up exporting an instantiation of the container), or similarly more totally unnecessary requirements on the type (cf. the QItemSelection example) Bikeshedding³: contains()/indexOf() use a linear scan, where's my member function for binary search, if I know the container is sorted? How can I decide the direction of the linear scan? Bikeshedding⁴: what are the parameters of contains()/indexOf() for a Container? T / const T &? But why not any K that you can compare against a T? Bikeshedding⁵: if there's indexOf() (returning an index), should there it be also a find() (returning an iterator)? If there's find(), should it there also be an indexOf()? Is it OK to have fundamentally duplicated APIs, and not strive for a good degree of minimality and simplicity? [we can go forward] > For the rest, free functions provide more flexibility. This statement is in contradiction with the previous ones. Containers are containers, and algorithms are algorithms; the library provides both as enabling mechanisms, the users decide how to mix and match them depending on the problem at hand. My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From michael.winkelmann at qt.io Thu Mar 23 11:45:46 2017 From: michael.winkelmann at qt.io (Michael Winkelmann) Date: Thu, 23 Mar 2017 11:45:46 +0100 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: <18416166.MC6PJ1Ml06@maurice> References: <18416166.MC6PJ1Ml06@maurice> Message-ID: <63afe00c-22c0-3404-6145-03f295c4a37e@qt.io> The reason why STL is using free function is because it separates data structures (aka containers) and algorithms. A bad example what happens if you dont separate can be seen here: https://www.imagemagick.org/api/Magick++/Image_8h_source.html ...and your data structure will be bloated with member functions. Personally, I would prefer having some STL convenience wrapper functions in Qt algorithm library. Cheers On 23.03.2017 08:32, Olivier Goffart wrote: > Hi everyone, > > I have been wondering if we should enhance Qt container with member functions > to help using some of the standard algorithm. > a peace of code is better than many words. We would be able to do: > > myList.sort(); > //or > myList.sort([](auto &a, auto &b){ return a.member < b.member; }); > > if (myList.contains([&value](const auto &elem){ return elem.id == value; })) > doSomething(); > > myList.removeIf([&](const auto &elem) { elem.field > someValue; }) > > > And these are a tad more convenient than using the standard library directly. > Compare to: > myList.erase(std::remove_if(myList.begin(), myList.end(), > [&](const auto &elem) { elem.field > someValue; }), > myList.end()); > > Of course, myList can be a QList, a QVector, or a QVarLenghtArray > > Here is an overview in how this could be implemented, should we want this: > https://codereview.qt-project.org/#/c/189313/ > > > Anyway, before I continue working on this patch, I want to know if this is > even something what the Qt Project wants. > > The reason we would want it are obvious: convenience. > > In the mean time, the standard is working on the so called range library. So > in C++20, you could maybe just write std::sort(myList). > But that's in the far future, and I want to be able to use it now. > There are already convenient range libraries that makes things convenient > available on github, but that's another dependency and the compatibility > guarantee are not the same. > > > The reason we would not want this is because this makes our containers too > convenient. The implementation of QVector is inferior to the one of > std::vector. (for example, it cannot contains move-only types). > Right now, it is quite easy to replace QVector by std::vector. But adding nice > feature to QVector may mean a reason to keep QVector longer in Qt6 instead of > changing to standard containers. > > Marc already expressed his opinion on the gerrit change, pointing out that we > deprecated qSort and the qt algorithm for a reason: the quality of the std > algorithm was better than the naive implementation in Qt. However this is just > a helper around the std algorithm implementation. > > > Why did we not added these function already in Qt 4.0? I was not there yet, > but I believe this might have been for technical reason: MSVC 6 was still > supported until Qt 4.5, which mans no template member functions. > Also sort needs an operator<, and non-template function might be instantiated > even if not used. > > So with this mail I would like to know what you think. If you think this is a > good idea or a terrible one. > > > Once we agreed the general idea is good, we can go into the details of the API > or implementation. > > On this WIP patch, I only took the algorithm that were most used within Qt and > QtCreator. I realize that QtCreator already has helper functions: > https://code.woboq.org/qt5/qt-creator/src/libs/utils/algorithm.h.html > That's I think one proof that shows that this would be useful. > > I am wondering if findIf shoud return a pointer or an iterator. > Returning a pointer allow things like > if (auto *elem = myContainer.findIf([&](const auto &elem) > { return elem.foo == bar; })) > elem->plop = myPlop; > > But does not work well if you want to find-then-remove: > auto it = std::find(myContainer.begin(), myContainer.end(), > [&](const auto &elem) { return elem.foo == bar; }); > if (it != myContainer.end()) { > myResult = *it; > myContainer.erase(it); // not possible if 'it' was a pointer > } > > So I'm afraid there will be much discussions and bike-shedding > > Regards -- --- Michael Winkelmann Qt Advisor The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin michael.winkelmann at qt.io +4915122973404 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B --- From konrad at silmor.de Thu Mar 23 11:51:02 2017 From: konrad at silmor.de (Konrad Rosenbaum) Date: Thu, 23 Mar 2017 11:51:02 +0100 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: <201703231036.06944.marc.mutz@kdab.com> References: <18416166.MC6PJ1Ml06@maurice> <201703231036.06944.marc.mutz@kdab.com> Message-ID: <1567709.tViG5Qxets@konradlnx> On Thursday, March 23, 2017 10:36:06 Marc Mutz wrote: > There're > proposals floating around for years to make o.f() fall back to f(o) for std > C++. Those are a lot more pain than you'd think! This construct already exists in C# (static extension classes/methods) and it is causing major headaches there - depending on your using statements (equiv. of #include) what looks like a simple method call can mean totally different things or not work at all! A change in a different section of the class that necessitates an additional using directive may cause all kinds of mayhem. It is a nightmare if you have to diagnose problems. In short: the recommendation in the C# world is: "do not use them unless you absolutely positively have no other choice." We should take that as a warning. Konrad -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From viktor.engelmann at qt.io Thu Mar 23 12:04:08 2017 From: viktor.engelmann at qt.io (Viktor Engelmann) Date: Thu, 23 Mar 2017 12:04:08 +0100 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: <1567709.tViG5Qxets@konradlnx> References: <18416166.MC6PJ1Ml06@maurice> <201703231036.06944.marc.mutz@kdab.com> <1567709.tViG5Qxets@konradlnx> Message-ID: I agree, but Marc actually just said that creator could suggest functions with signature f(T) when one presses . after an object o of type T. That's not the same as allowing the syntax o.f() to call f(o). On 23.03.2017 11:51, Konrad Rosenbaum wrote: > On Thursday, March 23, 2017 10:36:06 Marc Mutz wrote: >> There're >> proposals floating around for years to make o.f() fall back to f(o) for std >> C++. > Those are a lot more pain than you'd think! This construct already exists in > C# (static extension classes/methods) and it is causing major headaches there > - depending on your using statements (equiv. of #include) what looks like a > simple method call can mean totally different things or not work at all! A > change in a different section of the class that necessitates an additional > using directive may cause all kinds of mayhem. It is a nightmare if you have > to diagnose problems. > > In short: the recommendation in the C# world is: "do not use them unless you > absolutely positively have no other choice." We should take that as a warning. > > > Konrad > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin Viktor.Engelmann at qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Thu Mar 23 12:46:58 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 23 Mar 2017 12:46:58 +0100 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: <201703231036.06944.marc.mutz@kdab.com> References: <18416166.MC6PJ1Ml06@maurice> <201703231036.06944.marc.mutz@kdab.com> Message-ID: <6c11b4c2-bf34-c18e-1e0c-35d3a23355cd@kdab.com> Il 23/03/2017 10:36, Marc Mutz ha scritto: > Exactly. Bring back qSort(Container &), calling std::sort(std::begin(c), > std::end(c)). But leave the container interface alone. This could be done "right now" if we add them in a separate namespace. Whether changing qSort itself -- back in the day I didn't because it was a SIC. I would still be keen to call it a semi-unacceptable SIC today, even after 9 minor versions, as people do not compile code with deprecation warnings (*), so they have no idea that qSort should've not be used... (*) we had discussion at the last QtCS, and I had to write patches and a blog post about this, because our users didn't know! Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From jani.heikkinen at qt.io Thu Mar 23 14:17:02 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 23 Mar 2017 13:17:02 +0000 Subject: [Development] first Qt 5.9.0 beta snapshot available Message-ID: Hi all, We have finally first Qt 5.9.0 beta snapshot available via Qt Online Installer for mac and linux users, windows one coming later today or tomorrow morning. Snapshot is smoke tested & seems to be pretty much OK. Please download the snaphot (instructions here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer) & take a tour. Make sure all beta blockers are listed in https://bugreports.qt.io/issues/?filter=18394. br, Jani From milian.wolff at kdab.com Thu Mar 23 15:10:56 2017 From: milian.wolff at kdab.com (Milian Wolff) Date: Thu, 23 Mar 2017 15:10:56 +0100 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: <779413ad-b998-4f09-9dc2-f97ee54845b8@kdab.com> References: <18416166.MC6PJ1Ml06@maurice> <20170323105002.C645.6F0322A@gmail.com> <779413ad-b998-4f09-9dc2-f97ee54845b8@kdab.com> Message-ID: <6548320.B3DSWjtbHB@milian-kdab2> On Thursday, March 23, 2017 11:12:31 AM CET Giuseppe D'Angelo wrote: > Il 23/03/2017 10:50, Philippe ha scritto: > > I hardly imagine a "container" api without a "contains()" member. What I > > would call good sense. Qt already has this, std not. > > > > The other member that makes sense, if "indexOf()"... Qt already has this. > > Bikeshedding: this implies that your container contains a type > comparable for equality, but no sequential container enforces that (nor > it should), so this is effectively API pollution. > > Bikeshedding²: this also means more symbols exported (if you end up > exporting an instantiation of the container), or similarly more totally > unnecessary requirements on the type (cf. the QItemSelection example) > > Bikeshedding³: contains()/indexOf() use a linear scan, where's my member > function for binary search, if I know the container is sorted? How can I > decide the direction of the linear scan? > > Bikeshedding⁴: what are the parameters of contains()/indexOf() for a > Container? T / const T &? But why not any K that you can compare > against a T? > > Bikeshedding⁵: if there's indexOf() (returning an index), should there > it be also a find() (returning an iterator)? If there's find(), should > it there also be an indexOf()? Is it OK to have fundamentally duplicated > APIs, and not strive for a good degree of minimality and simplicity? > > [we can go forward] I'm very much with Peppe here. Olivier, please take these points into consideration. Bloating the API of a generic container with methods that are only usable for special circumstances is imo not a good idea. I am not opposed to having free functions which are giving you convenience. That's also what many of the existing convenience functions should have been in the first place, btw. Like QStringList::join etc. -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts From tor.arne.vestbo at qt.io Thu Mar 23 15:55:30 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Thu, 23 Mar 2017 15:55:30 +0100 Subject: [Development] PSA: Blacklisting test for CI-runs only Message-ID: Hi everyone, It's now possible to blacklist tests only when run in the CI. You do this by adding the 'ci' keyword to the normal list of keywords when blacklisting a test, eg: [someTestFunction] osx-10.8 ci See also https://bugreports.qt.io/browse/QTBUG-59564 This results in the test being blacklisted when running on OSX 10.8 in the CI (BPASS/BFAIL), but not on local machines (PASS/FAIL). This should typically be used for tests that are flakey, but can only be reproduced in the CI. That way we'll detect when the test fails in local testing and have a higher chance of fixing it. Please consider if the 'ci' keyword should be added when blacklisting new tests (or reviewing blacklistings). In most cases it should, as tests that can be reproduced locally should ideally be fixed instead of blacklisted. Cheers, Tor Arne From Simon.Hausmann at qt.io Thu Mar 23 16:14:27 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 23 Mar 2017 15:14:27 +0000 Subject: [Development] PSA: Blacklisting test for CI-runs only In-Reply-To: References: Message-ID: To emphasize on aspect of this PSA: This only works for tests in Qt 5.9 and onwards (once qtbase merged), not for older branches of Qt. Simon ________________________________ From: Development on behalf of Tor Arne Vestbø Sent: Thursday, March 23, 2017 3:55:30 PM To: development at qt-project.org Subject: [Development] PSA: Blacklisting test for CI-runs only Hi everyone, It's now possible to blacklist tests only when run in the CI. You do this by adding the 'ci' keyword to the normal list of keywords when blacklisting a test, eg: [someTestFunction] osx-10.8 ci See also https://bugreports.qt.io/browse/QTBUG-59564 This results in the test being blacklisted when running on OSX 10.8 in the CI (BPASS/BFAIL), but not on local machines (PASS/FAIL). This should typically be used for tests that are flakey, but can only be reproduced in the CI. That way we'll detect when the test fails in local testing and have a higher chance of fixing it. Please consider if the 'ci' keyword should be added when blacklisting new tests (or reviewing blacklistings). In most cases it should, as tests that can be reproduced locally should ideally be fixed instead of blacklisted. Cheers, Tor Arne _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewleaver at comcast.net Thu Mar 23 18:59:25 2017 From: ewleaver at comcast.net (Ed Leaver) Date: Thu, 23 Mar 2017 11:59:25 -0600 Subject: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug Message-ID: Hi. Two binary questions: 1. I've been doing some compile testing of Qt-5.8.0 on CentOS-6.8. Only one minor bug in non-critical (to me) component, simple work-around. Would like to test Qt-5.9.0-beta, see if there's an easy way to automatically disable qtgamepad/src/plugins/gamepads/evdev/qevdevgamepadbackend.cpp compilation for these old 2.6 kernels without manually editing evdev.pro, and check for any other problems. I was using gcc-5.4.0, but will attempt gcc-4.8.2 -no-std=c++11 in the next few days. If you think this worthwhile, have you a Qt-5.9.0-beta source tarball? 2. I may soon be involved with a large-ish Qt project. I haven't seen it yet, but might benefit from modern build system. I'm comfortable with qmake but will gladly do qbs if that is in fact the future. Is it? Thanks! From thiago.macieira at intel.com Thu Mar 23 19:20:17 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Mar 2017 11:20:17 -0700 Subject: [Development] QList In-Reply-To: <201703220927.55011.marc.mutz@kdab.com> References: <2884720.dci7Rcneo1@tjmaciei-mobl1> <201703220927.55011.marc.mutz@kdab.com> Message-ID: <1689267.xY0VSWVU7V@tjmaciei-mobl1> On quarta-feira, 22 de março de 2017 01:27:54 PDT Marc Mutz wrote: > On Wednesday 22 March 2017 07:37:27 Thiago Macieira wrote: > > Another thing I'd want is for QStringView to carry the pointer to the > > QArrayData like QString does. > > NAK to inheriting from QStringView, publicly or privately. NAK to adding > another pointer. > > If you need a base class for your Q6String, use QStringRef. I thought QStringView was supposed to deprecate QStringRef and thus we'd remove it in a later version. I can't very well derive the most important class in Qt from a deprecated class. > It's already got > what you want: tight coupling with QString. QStringView will not be that > base class. QStringView will model whatever std::string_view models. > Anything that pessimises QStringView as a wrapper around a char16_t literal > is not acceptable. Yeah, that is a concern I have. I'm loathe to add the extra pointer and I'd prefer not to. Like I said, for QString+QStringView, we can use the begin pointer with the extra bit set, but this won't work for QByteArray. > I understand that you sit on a pile of finished changes to QString just > waiting for Qt 6 to come around. And I welcome it (I think, we'll see when > you upload some of it to Gerrit). But leave QStringView out of it. Actually, the QStringView class makes me need to sit down and rewrite a lot of the code. The pile of changes to QArrayData, QTypedArrayData, QArrayDataPointer, QArrayDataOps is probably valid, along with the QVector rewrite and the moc reversal to not use QByteArrayPrivate, but QStringView invalidates many of the assumptions I had for QString. I am also assuming QByteArray should follow QString's lead in whatever it does. The changes have been public for 5 years. They're in my qtbase in GitLab[1]. They end with the commit "Cache the fact that a QString is US-ASCII only" (currently [2], but link will be invalid after my next rebase + push; also, I need to stop using QPair in it). [1] https://gitlab.com/thiagomacieira/qtbase/commits/master [2] https://gitlab.com/thiagomacieira/qtbase/commit/d965fe9cd15c432a1f4306739 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 23 19:25:01 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Mar 2017 11:25:01 -0700 Subject: [Development] QList In-Reply-To: References: <201703220927.55011.marc.mutz@kdab.com> Message-ID: <11846261.vq0rlVzhc4@tjmaciei-mobl1> On quarta-feira, 22 de março de 2017 02:36:19 PDT Edward Welbourne wrote: > Is there scope for a common (perhaps private) base, to be used by (at > least) QString and QStringView, something along the lines of a Java > interface ? That was an alternative I didn't post because I hadn't yet throught it through. Instead of QString privately inheriting from QStringView, both QString and QStringView would inherit from a QStringBase or QStringOps or whtever we call it, containing most of the common read-only code. If we inherit publicly, then we also save from having to have those annoying "using QStringView::indexOf;". But, like I said, not completely throught through yet. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 23 19:27:13 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Mar 2017 11:27:13 -0700 Subject: [Development] QList In-Reply-To: <201703220927.55011.marc.mutz@kdab.com> References: <2884720.dci7Rcneo1@tjmaciei-mobl1> <201703220927.55011.marc.mutz@kdab.com> Message-ID: <3839800.EQHgOQLkYg@tjmaciei-mobl1> On quarta-feira, 22 de março de 2017 01:27:54 PDT Marc Mutz wrote: > NAK to inheriting from QStringView, publicly or privately. NAK to adding > another pointer. BTW, just to be clear: I am not accepting this discussion as closed. I only had this idea a while ago, so I have not yet throught it completely through, so I reserve the right to discuss it later. In the mean time: why do you care if some class derives from QStringView? We certainly need to discuss the presence of an extra pointer inside, as that has a cost. But derivation? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ville.voutilainen at gmail.com Thu Mar 23 19:33:37 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Thu, 23 Mar 2017 20:33:37 +0200 Subject: [Development] QList In-Reply-To: <3839800.EQHgOQLkYg@tjmaciei-mobl1> References: <2884720.dci7Rcneo1@tjmaciei-mobl1> <201703220927.55011.marc.mutz@kdab.com> <3839800.EQHgOQLkYg@tjmaciei-mobl1> Message-ID: On 23 March 2017 at 20:27, Thiago Macieira wrote: > In the mean time: why do you care if some class derives from QStringView? > We certainly need to discuss the presence of an extra pointer inside, as that > has a cost. But derivation? A base class that a user can name is detectable in multiple inheritance scenarios. Once you add such a base, it becomes hard to remove it, regardless of its size. From thiago.macieira at intel.com Thu Mar 23 19:34:48 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Mar 2017 11:34:48 -0700 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: <18416166.MC6PJ1Ml06@maurice> References: <18416166.MC6PJ1Ml06@maurice> Message-ID: <1966631.DvAthUrzGq@tjmaciei-mobl1> On quinta-feira, 23 de março de 2017 00:32:14 PDT Olivier Goffart wrote: > Hi everyone, > > I have been wondering if we should enhance Qt container with member > functions to help using some of the standard algorithm. > a peace of code is better than many words. We would be able to do: [cut] I like the initiative, but the commenters have a good point to about free functions. We can probably find a balance between them, which functions are so common that should be members, and which ones we ought to leave free. If you can start throwing the idea around and see what you can come up with, we'll take it step-by-step. If not, let's have some time for this during QtCS later this year. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Thu Mar 23 20:13:09 2017 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Thu, 23 Mar 2017 16:13:09 -0300 Subject: [Development] Use of std::function in Qt API In-Reply-To: <1784128.X8e1dRBqdr@tjmaciei-mobl1> References: <1804385.6UHCisc69D@tonks> <1784128.X8e1dRBqdr@tjmaciei-mobl1> Message-ID: <2954098.VjBAENd079@tonks> On lunes, 20 de marzo de 2017 12:11:17 -03 Thiago Macieira wrote: > Em segunda-feira, 20 de março de 2017, às 11:53:50 PDT, Lisandro Damián > > Nicanor Pérez Meyer escreveu: > > In the (2) case it will mean that we distro packagers will be forced to > > change Qt's SONAME. Yeah, the whole of it. > > Why? We're not changing our ABI. To be clear: we're not proposing replacing > what we have right now with std::function, but adding it to new places as > the needs arise. > > The point however is that if libstdc++ does break its ABI, then you'll have > to rebuild half the world anyway. The few libraries and applications that > did use Qt and were not affected would be the minority. Telling them apart > could be a higher cost than just rebuilding -- remember, ALL C++ code links > to libstdc++, regardless of whether it was subject to the ABI break or not. > > And if libstdc++ changes its soname, then you HAVE to rebuild Qt and > everything, anyway. Right, but without a proper SONAME change we can not track what needs to get rebuilt and what doesn't (because it already was), what can migrate from unstable to testing, what binary is compatible with another and so on. Yes, on Debian we do really rely on the SONAME for this (+/- tricks, but that gets ugly). > > Oh, and if some non-other Qt api is exposed it should also become part of > > the SONAME. > > Again, why? We've exposed C and Xlib API for years and have never had "X11" > in the name (or "xcb" now). Maybe because they never broke? At least in the time I've been maintaining Qt in Debian we have never encountered an issue with this. This is from the last Qt 4 releases before Qt5. We do track symbols for each version+build+arch we do. We never found an ABI break on Qt, we do really hope to keep things like that, or have an appropiate method to deal with the situation. > Tell me of other libraries that follow this > naming scheme, because I haven't heard of them. The last time maintainers for other libs had to rename them "by hand" to do the proper transition, thus provinding stuff like libfoo5a instead of libfoo5. If I remember correctly boost was one of them. Yes, this is doable, but means we end up with a different naming scheme than uptream. Now if having distros with different SONAMEs for the same source code is acceptable (ie, it doesn't gets coordinated from the Qt project itself) then I see no reason to let this happen, after all the C++ ABI doesn't changes often. > But note I want to limit which API we're allowed to expose. I know, and I'm really grateful for that. > > So if we are going to only expose libstdc++'s API weshould really consider > > making it part of the SONAME. After all we discussed some time ago that > > the > > libstdc++ lib doesn't breaks BC so frequently. > > No, we shouldn't because it's the frigging C++ *Standard* *Library.* EVERY > single C++ application links to it, if you as much as used "new" in your > code. > > I've said this before: there's a way to split libstdc++ into two, so that > the library providing the base functionality (new/delete, typeinfo, > std::exception, cxxabi) is not the same library as the one providing the > higher-level functionality. That would allow sharing the base things that > all C++ applications and libraries need from the higher level classes, > including that of other implementations like libc++. > > Yet no Linux distribution does that. For 4 years many have provided libc++ > without opting to this solution. That tells me they are not interested in > providing binary compatibility between libstdc++ and other C++ standard > library implementations. As a consequence, if they are not, why should we > be? That's beyond me, as I never digged into it's maintainance. -- You know you're brilliant, but maybe you'd like to understand what you did 2 weeks from now. Linus Benedict Torvalds. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From marc.mutz at kdab.com Thu Mar 23 20:28:54 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 23 Mar 2017 20:28:54 +0100 Subject: [Development] QList In-Reply-To: <1689267.xY0VSWVU7V@tjmaciei-mobl1> References: <2884720.dci7Rcneo1@tjmaciei-mobl1> <201703220927.55011.marc.mutz@kdab.com> <1689267.xY0VSWVU7V@tjmaciei-mobl1> Message-ID: On 2017-03-23 19:20, Thiago Macieira wrote: > Actually, the QStringView class makes me need to sit down and rewrite a > lot of > the code. This I do not understand. QStringView has nothing to do with QString, any more than it has to do with std::u16string. Well, if you skip that idea with one inheriting the other. What kind of rewrite are you referring to? Thanks, Marc From thiago.macieira at intel.com Thu Mar 23 20:43:04 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Mar 2017 12:43:04 -0700 Subject: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug In-Reply-To: References: Message-ID: <1676263.q5QZILVYxz@tjmaciei-mobl1> On quinta-feira, 23 de março de 2017 10:59:25 PDT Ed Leaver wrote: > will attempt gcc-4.8.2 -no-std=c++11 in the next few days. If you think > this worthwhile, have you a Qt-5.9.0-beta source tarball? You can't turn C++11 off since 5.7.0. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Thu Mar 23 20:41:56 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 23 Mar 2017 20:41:56 +0100 Subject: [Development] QList In-Reply-To: <3839800.EQHgOQLkYg@tjmaciei-mobl1> References: <2884720.dci7Rcneo1@tjmaciei-mobl1> <201703220927.55011.marc.mutz@kdab.com> <3839800.EQHgOQLkYg@tjmaciei-mobl1> Message-ID: On 2017-03-23 19:27, Thiago Macieira wrote: > On quarta-feira, 22 de março de 2017 01:27:54 PDT Marc Mutz wrote: >> NAK to inheriting from QStringView, publicly or privately. NAK to >> adding >> another pointer. > > BTW, just to be clear: I am not accepting this discussion as closed. I > only > had this idea a while ago, so I have not yet throught it completely > through, > so I reserve the right to discuss it later. > > In the mean time: why do you care if some class derives from > QStringView? Because it's _wrong_. It does not model is-a, so public inheritance is out of the question. QString cannot use a lot of QStringView functions (like mid()) without changing at least the return type, so inherit-to-reuse-implementation is also not valid. Last, there are no virtual functions in QStringView that QString would want to reimplement. So, of the three use-cases for inheritance, none are relevant here, so it follows that inheritance is not the tool to use. You may consider composition, though, as I said, I'd rather provide free functions that most QString/View methods forward to than picking one class and calling its methods from all others. > We certainly need to discuss the presence of an extra pointer inside, > as that > has a cost. But derivation? Derivation is the strongest coupling mechanism in C++, after friendship. Do I need to mention QPolygon and what pain it's inheritance from QVector has caused? (FTR: cf. end of qvector.h and qvector_msvc.cpp). Thanks, Marc From thiago.macieira at intel.com Thu Mar 23 20:50:25 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Mar 2017 12:50:25 -0700 Subject: [Development] Use of std::function in Qt API In-Reply-To: <2954098.VjBAENd079@tonks> References: <1784128.X8e1dRBqdr@tjmaciei-mobl1> <2954098.VjBAENd079@tonks> Message-ID: <14629305.P2BaKxOfO2@tjmaciei-mobl1> On quinta-feira, 23 de março de 2017 12:13:09 PDT Lisandro Damián Nicanor Pérez Meyer wrote: > > The point however is that if libstdc++ does break its ABI, then you'll > > have > > to rebuild half the world anyway. The few libraries and applications that > > did use Qt and were not affected would be the minority. Telling them apart > > could be a higher cost than just rebuilding -- remember, ALL C++ code > > links > > to libstdc++, regardless of whether it was subject to the ABI break or > > not. > > > > And if libstdc++ changes its soname, then you HAVE to rebuild Qt and > > everything, anyway. > > Right, but without a proper SONAME change we can not track what needs to get > rebuilt and what doesn't (because it already was), what can migrate from > unstable to testing, what binary is compatible with another and so on. Understood, but that's not Qt's problem. If libc or libstdc++ cause a BC break, it's their responsibility to update the SONAME. If they don't, you (Debian) get to complain to them. Either way, the benefit of keeping Qt immune to those breaks is so small to the point that it's not worth it. > > > Oh, and if some non-other Qt api is exposed it should also become part > > > of > > > the SONAME. > > > > Again, why? We've exposed C and Xlib API for years and have never had > > "X11" > > in the name (or "xcb" now). > > Maybe because they never broke? At least in the time I've been maintaining > Qt in Debian we have never encountered an issue with this. This is from the > last Qt 4 releases before Qt5. Right and that's the entire point: there are some libraries (a whitelist) whose types we'll have in our public ABI, so Qt's ABI is then dependent on theirs. We'll only add libraries that have a good track record of keeping BC. So we'll not be having ICU or Boost any time soon in our public ABI. And we won't be adding C++1z types or those from TS's or anything std::experimental, because as GCC's page makes it very clear: they don't guarantee BC. > The last time maintainers for other libs had to rename them "by hand" to do > the proper transition, thus provinding stuff like libfoo5a instead of > libfoo5. If I remember correctly boost was one of them. Yes, this is > doable, but means we end up with a different naming scheme than uptream. Boost is not a BC citizen. > Now if having distros with different SONAMEs for the same source code is > acceptable (ie, it doesn't gets coordinated from the Qt project itself) then > I see no reason to let this happen, after all the C++ ABI doesn't changes > often. It's not acceptable. But I don't think it'll come to that. > > Yet no Linux distribution does that. For 4 years many have provided libc++ > > without opting to this solution. That tells me they are not interested in > > providing binary compatibility between libstdc++ and other C++ standard > > library implementations. As a consequence, if they are not, why should we > > be? > > That's beyond me, as I never digged into it's maintainance. And that's exactly my point: Linux distributions are not interested. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 23 20:54:53 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Mar 2017 12:54:53 -0700 Subject: [Development] QList In-Reply-To: References: <1689267.xY0VSWVU7V@tjmaciei-mobl1> Message-ID: <82812917.uQ0vy0D43l@tjmaciei-mobl1> On quinta-feira, 23 de março de 2017 12:28:54 PDT Marc Mutz wrote: > On 2017-03-23 19:20, Thiago Macieira wrote: > > Actually, the QStringView class makes me need to sit down and rewrite a > > lot of > > the code. > > This I do not understand. QStringView has nothing to do with QString, > any more than it has to do with std::u16string. Well, if you skip that > idea with one inheriting the other. What kind of rewrite are you > referring to? Well, it's dependent on the ability to derive from QStringView. As I said, I want to explore this possibility. There are three possible cases: 0) no derivation Then my QString and QByteArray updates are still mostly valid and can be taken in for Qt 6. The one change I probably want to make is to start using size_t and ssize_t like QStringView does. 1) deriving, but not adding the d pointer (so sizeof(QStringView) remains 2*sizeof(void*) In this case, this "rebasing" of QString on top of QStringView will eliminate a lot of code and require a large refactoring. 3) deriving and adding the d pointer (so sizeof(QStringView) becomes 3*sizeof(void*)) It's (1) plus more work. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 23 20:57:44 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Mar 2017 12:57:44 -0700 Subject: [Development] QList In-Reply-To: References: <3839800.EQHgOQLkYg@tjmaciei-mobl1> Message-ID: <4857168.tnRu1WynJn@tjmaciei-mobl1> On quinta-feira, 23 de março de 2017 11:33:37 PDT Ville Voutilainen wrote: > On 23 March 2017 at 20:27, Thiago Macieira wrote: > > In the mean time: why do you care if some class derives from QStringView? > > We certainly need to discuss the presence of an extra pointer inside, as > > that has a cost. But derivation? > > A base class that a user can name is detectable in multiple > inheritance scenarios. > Once you add such a base, it becomes hard to remove it, regardless of its > size. True, but remember I am proposing as a private base, so it's not exposed to others. Do you mean this: struct View { }; struct String : private View { }; struct UserCode : public String, public View {}; // warning: direct base 'View' inaccessible in 'UserCode' due to ambiguity https://godbolt.org/g/TsFS4l -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 23 21:11:16 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Mar 2017 13:11:16 -0700 Subject: [Development] QList In-Reply-To: <82812917.uQ0vy0D43l@tjmaciei-mobl1> References: <82812917.uQ0vy0D43l@tjmaciei-mobl1> Message-ID: <2519038.gVM7UG1Qb4@tjmaciei-mobl1> On quinta-feira, 23 de março de 2017 12:54:53 PDT Thiago Macieira wrote: > Then my QString and QByteArray updates are still mostly valid and can be > taken in for Qt 6. The one change I probably want to make is to start using > size_t and ssize_t like QStringView does. BTW, should we have a public typedef for this? QIntegerForSizeof::Signed is a mouthful. Note that this is not qptrdiff or qintptr, since in *theory* sizeof(size_t) need not be equal to sizeof(void*) (in practice, it is) and we wouldn't want "ptr" in the name anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 23 21:16:55 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Mar 2017 13:16:55 -0700 Subject: [Development] QList In-Reply-To: References: <3839800.EQHgOQLkYg@tjmaciei-mobl1> Message-ID: <1946478.CP59Q5S85h@tjmaciei-mobl1> On quinta-feira, 23 de março de 2017 12:41:56 PDT Marc Mutz wrote: > On 2017-03-23 19:27, Thiago Macieira wrote: > > In the mean time: why do you care if some class derives from > > QStringView? > > Because it's _wrong_. > > It does not model is-a, so public inheritance is out of the question. I beg to differ. It *is* "is-a": any modifiable QString is also a view to itself. Also, remember the point that it would be a private base, so the is-a relationship is not visible. This is about code reuse, not about the semantic. > QString cannot use a lot of QStringView functions (like mid()) without > changing at least the return type, so inherit-to-reuse-implementation is > also not valid. For some cases, that's true, but only because functions like mid() try to return *this if they detect that there's no change. That's an optimisation inside QString, not a requirement of the interface. A naïve implementation of QString::mid() could be: QString QString::mid(int start, int len) const { return QString(QStringView::mid(start, len)); } > Last, there are no virtual functions in QStringView that QString would > want to reimplement. Virtual has nothing to do with anything. QString is complementing QStringView, only adding functionality. > So, of the three use-cases for inheritance, none are relevant here, so > it follows that inheritance is not the tool to use. You may consider > composition, though, as I said, I'd rather provide free functions that > most QString/View methods forward to than picking one class and calling > its methods from all others. From a strict theoretical point of view, that might be better. From the practical point of view, implementing something as simple as int QString::indexOf(QChar ch, int from, Qt::CaseSensitivity cs) const { return QStringView(*this).indexOf(c, from, cs); } means: 1) we have an extra entry point in the library 2) so more symbols in the symbol table, increasing the chances of hash collision 3) more code that, at best, inlines QStringView::indexOf into the new function. That is, the best we can hope for is that the compiler turns the above into: int QString::indexOf(QChar ch, int from, Qt::CaseSensitivity cs) const { return findChar(unicode(), length(), ch, from, cs); } Also note we'd probably want to mark findChar as Q_NEVER_INLINE so that the compiler doesn't expand the same function twice, which would mean an even bigger QtCore. > > We certainly need to discuss the presence of an extra pointer inside, > > as that > > has a cost. But derivation? > > Derivation is the strongest coupling mechanism in C++, after friendship. > Do I need to mention QPolygon and what pain it's inheritance from > QVector has caused? (FTR: cf. end of qvector.h and > qvector_msvc.cpp). Because MSVC ABI, like the Windows ABI, has severe shortcomings and actually violate the C and C++ standards. Some of them are legacy reasons from the 1980s, like the one causing crashes reported in QTBUG-38876 (attempt for Qt 6 fix at https://codereview.qt-project.org/189193 ). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ville.voutilainen at gmail.com Thu Mar 23 21:17:21 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Thu, 23 Mar 2017 22:17:21 +0200 Subject: [Development] QList In-Reply-To: <4857168.tnRu1WynJn@tjmaciei-mobl1> References: <3839800.EQHgOQLkYg@tjmaciei-mobl1> <4857168.tnRu1WynJn@tjmaciei-mobl1> Message-ID: On 23 March 2017 at 21:57, Thiago Macieira wrote: >> A base class that a user can name is detectable in multiple >> inheritance scenarios. >> Once you add such a base, it becomes hard to remove it, regardless of its >> size. > > True, but remember I am proposing as a private base, so it's not exposed to > others. > > Do you mean this: > > struct View { }; > struct String : private View { }; > > struct UserCode : public String, public View {}; > // warning: direct base 'View' inaccessible in 'UserCode' due to ambiguity Yes, such an example is certainly one way how even a private base is significant for user code. From thiago.macieira at intel.com Thu Mar 23 21:36:41 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Mar 2017 13:36:41 -0700 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: <201703231036.06944.marc.mutz@kdab.com> References: <18416166.MC6PJ1Ml06@maurice> <201703231036.06944.marc.mutz@kdab.com> Message-ID: <1961561.bgEDc3jSGP@tjmaciei-mobl1> On quinta-feira, 23 de março de 2017 02:36:06 PDT Marc Mutz wrote: > Second, that member functions always get their *this argument passed by > reference. A free function can take the argument by value instead. The example for this is actually in the other thread: QStringView::indexOf(). If you write: QStringView(u"Hello").indexOf(u'l'); The compiler has to load the address of the u"Hello" literal and the size (5), then save them to a temporary in the stack, then load the address of that temporary into the register and call the target function. A free function passing QStringView by value would (not on Windows[*]) pass the address of the literal and the length as parameters. Compare the f and g functions in https://godbolt.org/g/lV5Swu. How to solve this? Easy, inline indexOf redirecting the call to the free function, as in https://godbolt.org/g/GFRxKU. [*] Why not on Windows? Change the compiler to Clang and add -target x86_64-mingw you'll see that now f and g are identical in both cases. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Thu Mar 23 21:46:24 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 23 Mar 2017 21:46:24 +0100 Subject: [Development] QList In-Reply-To: <2519038.gVM7UG1Qb4@tjmaciei-mobl1> References: <82812917.uQ0vy0D43l@tjmaciei-mobl1> <2519038.gVM7UG1Qb4@tjmaciei-mobl1> Message-ID: <201703232146.24874.marc.mutz@kdab.com> On Thursday 23 March 2017 21:11:16 Thiago Macieira wrote: > On quinta-feira, 23 de março de 2017 12:54:53 PDT Thiago Macieira wrote: > > Then my QString and QByteArray updates are still mostly valid and can be > > taken in for Qt 6. The one change I probably want to make is to start > > using size_t and ssize_t like QStringView does. > > BTW, should we have a public typedef for this? > > QIntegerForSizeof::Signed > > is a mouthful. qssize_t ? > Note that this is not qptrdiff or qintptr, since in *theory* sizeof(size_t) > need not be equal to sizeof(void*) (in practice, it is) and we wouldn't > want "ptr" in the name anyway. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From ewleaver at comcast.net Thu Mar 23 21:57:07 2017 From: ewleaver at comcast.net (Ed Leaver) Date: Thu, 23 Mar 2017 14:57:07 -0600 Subject: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug In-Reply-To: <1676263.q5QZILVYxz@tjmaciei-mobl1> References: <1676263.q5QZILVYxz@tjmaciei-mobl1> Message-ID: On 03/23/2017 01:43 PM, Thiago Macieira wrote: > On quinta-feira, 23 de março de 2017 10:59:25 PDT Ed Leaver wrote: >> will attempt gcc-4.8.2 -no-std=c++11 in the next few days. If you think >> this worthwhile, have you a Qt-5.9.0-beta source tarball? > You can't turn C++11 off since 5.7.0. > Thanks. Saved me some time and confusion. I didn't /personally/ wish to turn off C++11 anyway. I'll try 5.7.0 then against gcc-4.8.2, but am still interested in a 5.9.0-beta source tarball to test with gcc-5.4.0 and later, if such beta tarball becomes available. -------------- next part -------------- An HTML attachment was scrubbed... URL: From enmarantispam at gmail.com Thu Mar 23 22:01:38 2017 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Fri, 24 Mar 2017 00:01:38 +0300 Subject: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug In-Reply-To: References: <1676263.q5QZILVYxz@tjmaciei-mobl1> Message-ID: I am not entirely sure about BIG projects, but my medium sized one works fine with qbs, there are even some custom modules thrown in that handle .proto and grpc files for code generation and it works like magic. Doesnt exactly support qtlinguist atm though, so you will have to find a way around that. On Thu, Mar 23, 2017 at 11:57 PM, Ed Leaver wrote: > On 03/23/2017 01:43 PM, Thiago Macieira wrote: > > On quinta-feira, 23 de março de 2017 10:59:25 PDT Ed Leaver wrote: > > will attempt gcc-4.8.2 -no-std=c++11 in the next few days. If you think > this worthwhile, have you a Qt-5.9.0-beta source tarball? > > You can't turn C++11 off since 5.7.0. > > > Thanks. Saved me some time and confusion. I didn't *personally* wish to > turn off C++11 anyway. I'll try 5.7.0 then against gcc-4.8.2, but am still > interested in a 5.9.0-beta source tarball to test with gcc-5.4.0 and later, > if such beta tarball becomes available. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Thu Mar 23 22:12:23 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 23 Mar 2017 22:12:23 +0100 Subject: [Development] QList In-Reply-To: <1946478.CP59Q5S85h@tjmaciei-mobl1> References: <1946478.CP59Q5S85h@tjmaciei-mobl1> Message-ID: <201703232212.23215.marc.mutz@kdab.com> On Thursday 23 March 2017 21:16:55 Thiago Macieira wrote: > On quinta-feira, 23 de março de 2017 12:41:56 PDT Marc Mutz wrote: > > On 2017-03-23 19:27, Thiago Macieira wrote: > > > In the mean time: why do you care if some class derives from > > > QStringView? > > > > Because it's _wrong_. > > > > It does not model is-a, so public inheritance is out of the question. > > I beg to differ. It *is* "is-a": any modifiable QString is also a view to > itself. "is-a" is a terminus technicus. It means is-subtype-of aka. https://en.wikipedia.org/wiki/Liskov_substitution_principle > Also, remember the point that it would be a private base, so the is-a > relationship is not visible. This is about code reuse, not about the > semantic. If it's private inheritance, it's not is-a. > > QString cannot use a lot of QStringView functions (like mid()) without > > changing at least the return type, so inherit-to-reuse-implementation is > > also not valid. > > For some cases, that's true, but only because functions like mid() try to > return *this if they detect that there's no change. That's an optimisation > inside QString, not a requirement of the interface. > > A naïve implementation of QString::mid() could be: > > QString QString::mid(int start, int len) const > { > return QString(QStringView::mid(start, len)); > } Which is no different from return QString(QStringView(*this).mid(start, len)); so does not provide a case supporting using inhertance. > > Last, there are no virtual functions in QStringView that QString would > > want to reimplement. > > Virtual has nothing to do with anything. QString is complementing > QStringView, only adding functionality. I'm merely listing the use-cases for inheritance. Good that you agree that none appy :) > > So, of the three use-cases for inheritance, none are relevant here, so > > it follows that inheritance is not the tool to use. You may consider > > composition, though, as I said, I'd rather provide free functions that > > most QString/View methods forward to than picking one class and calling > > its methods from all others. > > From a strict theoretical point of view, that might be better. > > From the practical point of view, implementing something as simple as > > int QString::indexOf(QChar ch, int from, Qt::CaseSensitivity cs) const > { > return QStringView(*this).indexOf(c, from, cs); > } I said it many time, and I'll say it once more: The way to share code is through free functions, not one class delegating to another: return qFindChar(*this, ch, from, cs); or return qFindString(*this, QStringView(&ch, 1), from, cs); where only the qFoo() functions are exported, but none of the QString/View/Ref members. > means: > 1) we have an extra entry point in the library > 2) so more symbols in the symbol table, increasing the chances of hash > collision > 3) more code that, at best, inlines QStringView::indexOf into the new > function. That is, the best we can hope for is that the compiler turns > the above into: > > int QString::indexOf(QChar ch, int from, Qt::CaseSensitivity cs) const > { > return findChar(unicode(), length(), ch, from, cs); > } > > Also note we'd probably want to mark findChar as Q_NEVER_INLINE so that the > compiler doesn't expand the same function twice, which would mean an even > bigger QtCore. Note how all of those concerns are addressed by qCompareStrings()-like delegation to free functions. > > > We certainly need to discuss the presence of an extra pointer inside, > > > as that > > > has a cost. But derivation? > > > > Derivation is the strongest coupling mechanism in C++, after friendship. > > Do I need to mention QPolygon and what pain it's inheritance from > > QVector has caused? (FTR: cf. end of qvector.h and > > qvector_msvc.cpp). > > Because MSVC ABI, like the Windows ABI, has severe shortcomings and > actually violate the C and C++ standards. Some of them are legacy reasons > from the 1980s, like the one causing crashes reported in QTBUG-38876 > (attempt for Qt 6 fix at https://codereview.qt-project.org/189193 ). I'm merely pointing out that inheriting one value class from another, even publicly (but the same problem would exist with private inheritance, I guess?), has already caused much pain. We should learn from it two things: 1. not inhert one value type from another 2. not class-level-export value classes, only export out-of-line functions Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Thu Mar 23 22:22:36 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Mar 2017 14:22:36 -0700 Subject: [Development] QList In-Reply-To: <201703232212.23215.marc.mutz@kdab.com> References: <1946478.CP59Q5S85h@tjmaciei-mobl1> <201703232212.23215.marc.mutz@kdab.com> Message-ID: <35533789.cmIqBDbaWG@tjmaciei-mobl1> On quinta-feira, 23 de março de 2017 14:12:23 PDT Marc Mutz wrote: > > I beg to differ. It *is* "is-a": any modifiable QString is also a view to > > itself. > > "is-a" is a terminus technicus. It means is-subtype-of aka. > https://en.wikipedia.org/wiki/Liskov_substitution_principle > > > Also, remember the point that it would be a private base, so the is-a > > relationship is not visible. This is about code reuse, not about the > > semantic. > > If it's private inheritance, it's not is-a. You're contradicting yourself now. If private inheritance is not is-a, then you can't tell me not to use private inheritance because QString isn't a QStringView. I don't want QStringView to appear to users as a base of QString. I just want code reuse. > > A naïve implementation of QString::mid() could be: > > > > QString QString::mid(int start, int len) const > > { > > > > return QString(QStringView::mid(start, len)); > > > > } > > Which is no different from > > return QString(QStringView(*this).mid(start, len)); > > so does not provide a case supporting using inhertance. Actually, the code generation could be slightly different. If QStringView::mid() isn't inlined, then the difference is whether we need to create a temporary QStringView in the stack and pass its this pointer as a parameter. > > > Last, there are no virtual functions in QStringView that QString would > > > want to reimplement. > > > > Virtual has nothing to do with anything. QString is complementing > > QStringView, only adding functionality. > > I'm merely listing the use-cases for inheritance. Good that you agree that > none appy :) I'm saying that virtual is not a requirement, therefore not having is not to the detriment of the solution. > I said it many time, and I'll say it once more: The way to share code is > through free functions, not one class delegating to another: There's still a difference. > > return qFindChar(*this, ch, from, cs); > > or > > return qFindString(*this, QStringView(&ch, 1), from, cs); > > where only the qFoo() functions are exported, but none of the > QString/View/Ref members. I don't think we're going to go that far. Doing so would mean a lot of work to unexport the entire class and provide only free functions for the entirety of the QString/QStringView API. Not to mention that we'd have source duplication, which is a source of both copy & paste errors and lack of copy & paste to add functions. I'd rather follow DRY. > Note how all of those concerns are addressed by qCompareStrings()-like > delegation to free functions. Except for the concern that it adds of source code duplication. > > Because MSVC ABI, like the Windows ABI, has severe shortcomings and > > actually violate the C and C++ standards. Some of them are legacy reasons > > from the 1980s, like the one causing crashes reported in QTBUG-38876 > > (attempt for Qt 6 fix at https://codereview.qt-project.org/189193 ). > > I'm merely pointing out that inheriting one value class from another, even > publicly (but the same problem would exist with private inheritance, I > guess?), has already caused much pain. We should learn from it two things: > > 1. not inhert one value type from another > 2. not class-level-export value classes, only export out-of-line functions I disagree with those learnings. The issue we have is deriving an exported class from a non-exported class, because suddenly all the inlines from the regular class become exported. It's a worse scenario when the base class was a template. Deriving from an exported class has never been a problem. As for doing (member) function-level exports, they're just ugly and violate DRY. We need very good reasons not to simply export the class itself. Finally, exporting some free, low-level functions sounds like an acceptable idea. There's no reason not to have qstrlen and qstrchr operating on UTF-16, since neither the C or the C++ libraries offer that functionality. The only question is whether they should depend on QStringView or whether they should take the char16_t pointer and length. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 23 22:25:43 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Mar 2017 14:25:43 -0700 Subject: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug In-Reply-To: References: <1676263.q5QZILVYxz@tjmaciei-mobl1> Message-ID: <3221217.Il3lxehdtr@tjmaciei-mobl1> On quinta-feira, 23 de março de 2017 13:57:07 PDT Ed Leaver wrote: > On 03/23/2017 01:43 PM, Thiago Macieira wrote: > > On quinta-feira, 23 de março de 2017 10:59:25 PDT Ed Leaver wrote: > >> will attempt gcc-4.8.2 -no-std=c++11 in the next few days. If you think > >> this worthwhile, have you a Qt-5.9.0-beta source tarball? > > > > You can't turn C++11 off since 5.7.0. > > Thanks. Saved me some time and confusion. I didn't /personally/ wish to > turn off C++11 anyway. I'll try 5.7.0 then against gcc-4.8.2, but am > still interested in a 5.9.0-beta source tarball to test with gcc-5.4.0 > and later, if such beta tarball becomes available. Hello Ed I have no idea what BTN_TRIGGER_HAPPY is. But you can simply disable qtgamepad entirely if you don't plan on using it. Either don't download it, or rm -rf the subdir after you've downloaded it, or pass -skip qtgamepad to the compilation. You should also report the failure to built from sources (FTBFS) and indicate which kernel version your headers are from. Since it's a macro, it is easy to just #ifdef around its existence. But I don't know whether the developer will accept the bug or they will say "sorry, your kernel is way too old, try upgrading". What kernel is that, BTW? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 23 22:26:21 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Mar 2017 14:26:21 -0700 Subject: [Development] QList In-Reply-To: <201703232146.24874.marc.mutz@kdab.com> References: <2519038.gVM7UG1Qb4@tjmaciei-mobl1> <201703232146.24874.marc.mutz@kdab.com> Message-ID: <4089122.Z3HWMNXIgG@tjmaciei-mobl1> On quinta-feira, 23 de março de 2017 13:46:24 PDT Marc Mutz wrote: > On Thursday 23 March 2017 21:11:16 Thiago Macieira wrote: > > On quinta-feira, 23 de março de 2017 12:54:53 PDT Thiago Macieira wrote: > > > Then my QString and QByteArray updates are still mostly valid and can be > > > taken in for Qt 6. The one change I probably want to make is to start > > > using size_t and ssize_t like QStringView does. > > > > BTW, should we have a public typedef for this? > > > > QIntegerForSizeof::Signed > > > > is a mouthful. > > qssize_t ? That's what I'm leaning towards, since POSIX has ssize_t. Before anyone asks: why not ssize_t? Because Windows is not POSIX. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philwave at gmail.com Thu Mar 23 22:30:58 2017 From: philwave at gmail.com (Philippe) Date: Thu, 23 Mar 2017 22:30:58 +0100 Subject: [Development] QList In-Reply-To: <35533789.cmIqBDbaWG@tjmaciei-mobl1> References: <201703232212.23215.marc.mutz@kdab.com> <35533789.cmIqBDbaWG@tjmaciei-mobl1> Message-ID: <20170323223057.CFFE.6F0322A@gmail.com> On Thu, 23 Mar 2017 14:22:36 -0700 Thiago Macieira wrote: > > > > return qFindChar(*this, ch, from, cs); > > > > or > > > > return qFindString(*this, QStringView(&ch, 1), from, cs); > > > > where only the qFoo() functions are exported, but none of the > > QString/View/Ref members. > > I don't think we're going to go that far. Doing so would mean a lot of work to > unexport the entire class and provide only free functions for the entirety of > the QString/QStringView API. Indeed, let me quote Scott Meyer, in his paper "How Non-Member Functions Improve Encapsulation" "Based on his work with various string-like classes, Jack Reeves has observed that some functions just don't "feel" right when made non-members, even if they could be non-friend non-members. The "best" interface for a class can be found only by balancing many competing concerns, of which the degree of encapsulation is but one." http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197?pgno=3 From ewleaver at comcast.net Thu Mar 23 22:54:20 2017 From: ewleaver at comcast.net (Ed Leaver) Date: Thu, 23 Mar 2017 15:54:20 -0600 Subject: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug In-Reply-To: <3221217.Il3lxehdtr@tjmaciei-mobl1> References: <1676263.q5QZILVYxz@tjmaciei-mobl1> <3221217.Il3lxehdtr@tjmaciei-mobl1> Message-ID: <31e6beda-fb72-0a50-d1d4-bc1f8f3ba38e@comcast.net> Hi Thiago, BTN_TRIGGER_HAPPYxy are a group of kernel #defines, apparently for drivers not supported by the 2.6 kernels. Here are my dev notes: ... Qt-5.8.0 then compiled against gcc-5.4.0 with only one minor problem: qt-everywhere-opensource-src-5.8.0/qtgamepad/src/plugins/gamepads/evdev/qevdevgamepadbackend.cpp does not compile on CentOS-6.8 (apparently) because the 2.6.32-642.el6.x86_64 kernel is too old and does not define BTN_TRIGGER_HAPPYn (n=1,2,3,4). On Fedora 25 these are in /lib/modules/4.9.14-200.fc25.x86_64/build/include/dt-bindings/input/linux-event-codes.h I patched qevdevgamepadbackend.cpp with those values: #ifndef BTN_TRIGGER_HAPPY1 #define BTN_TRIGGER_HAPPY1 0x2c0 #define BTN_TRIGGER_HAPPY2 0x2c1 #define BTN_TRIGGER_HAPPY3 0x2c2 #define BTN_TRIGGER_HAPPY4 0x2c3 #endif directly above QEvdevGamepadDevice::resetConfiguration(), and then the whole Qt-5.8.0 source compiles just fine (gcc-5.4.0), although there is a minor issue with final "make install" with /usr/bin/ld not having permission to open a file named "terminal". This might not be critical, need to see. It may be because I paused the CentOS-6 VM at one point during the build, when it was building on a partition NFS exported from the host. HOWEVER, the above #ifndef BTN_TRIGGER_HAPPY1 patch is unsatisfactory, as it allows m_buttonsMap[BTN_TRIGGER_HAPPY1] = QGamepadManager::ButtonLeft; etc assignments to array elements that the kernel probably does not know about. Far safer to disable this particular gamepad plugin in qtgamepad/src/plugins/gamepads/gamepads.pro I'll probably never need this gamepad controller, and if I ever do, it won't be on CentOS-6 Thanks again, Ed On 03/23/2017 03:25 PM, Thiago Macieira wrote: > On quinta-feira, 23 de março de 2017 13:57:07 PDT Ed Leaver wrote: >> On 03/23/2017 01:43 PM, Thiago Macieira wrote: >>> On quinta-feira, 23 de março de 2017 10:59:25 PDT Ed Leaver wrote: >>>> will attempt gcc-4.8.2 -no-std=c++11 in the next few days. If you think >>>> this worthwhile, have you a Qt-5.9.0-beta source tarball? >>> You can't turn C++11 off since 5.7.0. >> Thanks. Saved me some time and confusion. I didn't /personally/ wish to >> turn off C++11 anyway. I'll try 5.7.0 then against gcc-4.8.2, but am >> still interested in a 5.9.0-beta source tarball to test with gcc-5.4.0 >> and later, if such beta tarball becomes available. > Hello Ed > > I have no idea what BTN_TRIGGER_HAPPY is. But you can simply disable qtgamepad > entirely if you don't plan on using it. Either don't download it, or rm -rf > the subdir after you've downloaded it, or pass -skip qtgamepad to the > compilation. > > You should also report the failure to built from sources (FTBFS) and indicate > which kernel version your headers are from. Since it's a macro, it is easy to > just #ifdef around its existence. But I don't know whether the developer will > accept the bug or they will say "sorry, your kernel is way too old, try > upgrading". > > What kernel is that, BTW? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Mar 24 00:42:43 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Mar 2017 16:42:43 -0700 Subject: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug In-Reply-To: <31e6beda-fb72-0a50-d1d4-bc1f8f3ba38e@comcast.net> References: <3221217.Il3lxehdtr@tjmaciei-mobl1> <31e6beda-fb72-0a50-d1d4-bc1f8f3ba38e@comcast.net> Message-ID: <1588347.cVtcoo8qP6@tjmaciei-mobl1> On quinta-feira, 23 de março de 2017 14:54:20 PDT Ed Leaver wrote: > Hi Thiago, > > BTN_TRIGGER_HAPPYxy are a group of kernel #defines, apparently for > drivers not supported by the 2.6 kernels. Here are my dev notes: > > ... Qt-5.8.0 then compiled against gcc-5.4.0 with only one minor > problem: > > qt-everywhere-opensource-src-5.8.0/qtgamepad/src/plugins/gamepads/evdev/qev > devgamepadbackend.cpp does not compile on CentOS-6.8 (apparently) because > the > 2.6.32-642.el6.x86_64 kernel is too old > and does not define BTN_TRIGGER_HAPPYn (n=1,2,3,4). On Fedora 25 > these are in > > /lib/modules/4.9.14-200.fc25.x86_64/build/include/dt-bindings/input/linux-e > vent-codes.h I patched qevdevgamepadbackend.cpp with those values: > #ifndef BTN_TRIGGER_HAPPY1 > #define BTN_TRIGGER_HAPPY1 0x2c0 > #define BTN_TRIGGER_HAPPY2 0x2c1 > #define BTN_TRIGGER_HAPPY3 0x2c2 > #define BTN_TRIGGER_HAPPY4 0x2c3 > #endif > directly above QEvdevGamepadDevice::resetConfiguration(), and then > the whole Qt-5.8.0 source compiles > just fine (gcc-5.4.0), although there is a minor issue with final Please report this issue up to here. The developer will determine whether the #define is acceptable or not. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Mar 24 01:01:23 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Mar 2017 17:01:23 -0700 Subject: [Development] [Interest] pushing a WIP In-Reply-To: References: Message-ID: <1883461.aPX4CrYs6E@tjmaciei-mobl1> On quarta-feira, 22 de março de 2017 10:17:03 PDT Patrick Stinson wrote: > I am not new to git but am new to growing out of using git as if it were > svn. I have a local work in progress branch (apple--pencil) based on dev, > and want to know how to push it to a feature branch on dev. Should I just > do Hello Patrick This discussion belongs in the development mailing list. Please drop interest from Cc when you reply. (I'd usually Bcc, but then mailman will not allow the post to happen) > git push origin dev Actually: git push origin dev:refs/for/dev Assuming that: a) origin is the Gerrit remote b) dev is the name of your local branch refs/for/dev is literal like that, don't change it. Note we don't usually want people to clone from Gerrit and pull from it. You should clone from code.qt.io and then have a separate remote (usually called "gerrit") for pushing the changes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kuba at mareimbrium.org Fri Mar 24 01:42:14 2017 From: kuba at mareimbrium.org (Kuba Ober) Date: Thu, 23 Mar 2017 20:42:14 -0400 Subject: [Development] QList In-Reply-To: <35533789.cmIqBDbaWG@tjmaciei-mobl1> References: <1946478.CP59Q5S85h@tjmaciei-mobl1> <201703232212.23215.marc.mutz@kdab.com> <35533789.cmIqBDbaWG@tjmaciei-mobl1> Message-ID: <3DAD9FF3-CACB-4D3E-B654-30540A9291B1@mareimbrium.org> 23 mars 2017 kl. 17:22 skrev Thiago Macieira : > > You're contradicting yourself now. If private inheritance is not is-a, then > you can't tell me not to use private inheritance because QString isn't a > QStringView. > > I don't want QStringView to appear to users as a base of QString. I just want > code reuse. I agree. Public and non-public derivation in C++ have vastly different meaning. Public derivation means is-a in the technical sense of LSP. Non-public derivation is an implementation detail that expresses has-a in a way that allows easier use or re-exposure of the members of the base class. It has to do with semantics of C++ and has zilch to do with OO design. Cheers, Kuba From marc.mutz at kdab.com Fri Mar 24 09:34:18 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 24 Mar 2017 09:34:18 +0100 Subject: [Development] QList In-Reply-To: <35533789.cmIqBDbaWG@tjmaciei-mobl1> References: <201703232212.23215.marc.mutz@kdab.com> <35533789.cmIqBDbaWG@tjmaciei-mobl1> Message-ID: <201703240934.18483.marc.mutz@kdab.com> Hi Thiago, You misunderstand me. I listed _the_ three use-cases where inheritance is the tool of choice: 1. modelling is-a 2. inheriting to reuse 3. reimplementing virtual functions If your use-case is not one of the three, then inheritance is not the right tool. Clearly, by now, it's neither (1) nor (3). So if anything, it needs to be (2). And I'm arguing that it's not (2), either, because you can only re-use a subset of QStringView API, and need to wrap the other half anyway. (2) is really only interesting for pure OO languages with no concept of free functions. In C++, we have free functions. On Thursday 23 March 2017 22:22:36 Thiago Macieira wrote: > > > A naïve implementation of QString::mid() could be: > > > > > > > > > QString QString::mid(int start, int len) const > > > { > > > return QString(QStringView::mid(start, len)); > > > } > > > > Which is no different from > > > > return QString(QStringView(*this).mid(start, len)); > > > > > > so does not provide a case supporting using inhertance. > > Actually, the code generation could be slightly different. If > QStringView::mid() isn't inlined, then the difference is whether we need > to create a temporary QStringView in the stack and pass its this pointer > as a parameter. If QStringView::mid() isn't inline, then it doesn't matter which implementation we choose. The implicit this in QStringView::mid is still there, forcing the object on the stack. So what I take away from this discussion is "avoid having to go though *this (into out-of-line code)". And to avoid having to go through *this, you need free functions, not member functions of some private base class. And this is what I intend to do: QStringView::mid is inline. And I'm proposing to make all QString/View member functions inline non-exported, either implemented directly or by calling a free function (exported or not). As an aside: going through *this has obviously so far not been an issue with QString's myriads of member functions, so I guess even on Win64 calling performance will increase with QStringView taken by value. Ville: are there any proposals for making *this passable by value? Like struct QLineF { Q_CORE_EXPORT QPointF intersection(QLineF other) =; // =: pass *this by value, mimicking & and && for (l|r)value ref }; Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From ville.voutilainen at gmail.com Fri Mar 24 09:50:27 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Fri, 24 Mar 2017 10:50:27 +0200 Subject: [Development] QList In-Reply-To: <201703240934.18483.marc.mutz@kdab.com> References: <201703232212.23215.marc.mutz@kdab.com> <35533789.cmIqBDbaWG@tjmaciei-mobl1> <201703240934.18483.marc.mutz@kdab.com> Message-ID: On 24 March 2017 at 10:34, Marc Mutz wrote: > Ville: are there any proposals for making *this passable by value? Like > > struct QLineF { > Q_CORE_EXPORT QPointF intersection(QLineF other) =; > // =: pass *this by value, mimicking & and && for (l|r)value ref > }; No, I have never seen such an idea being suggested before this discussion. From edward.welbourne at qt.io Fri Mar 24 10:37:56 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 24 Mar 2017 09:37:56 +0000 Subject: [Development] Use of std::function in Qt API In-Reply-To: <14629305.P2BaKxOfO2@tjmaciei-mobl1> References: <1784128.X8e1dRBqdr@tjmaciei-mobl1> <2954098.VjBAENd079@tonks>,<14629305.P2BaKxOfO2@tjmaciei-mobl1> Message-ID: Earlier, Thiago said: >>> The point however is that if libstdc++ does break its ABI, then >>> you'll have to rebuild half the world anyway. The few libraries and >>> applications that did use Qt and were not affected would be the >>> minority. Telling them apart could be a higher cost than just >>> rebuilding -- remember, ALL C++ code links to libstdc++, regardless >>> of whether it was subject to the ABI break or not. >>> >>> And if libstdc++ changes its soname, then you HAVE to rebuild Qt and >>> everything, anyway. On quinta-feira, 23 de março de 2017 12:13:09 PDT Lisandro Damián Nicanor Pérez Meyer wrote: >> Right, but without a proper SONAME change we can not track what needs >> to get rebuilt and what doesn't (because it already was), what can >> migrate from unstable to testing, what binary is compatible with >> another and so on. Let me just check I've understood this one correctly: you need the SONAME change as soon as we introduce any stl type in our API because, regardless of it being new API, during the lifetime of that version of Qt, there may be changes to the stl ABI, that would break Qt. So the existing Qt SONAME needs to express the stl ABI version so that, after the update, things built before pick up the old Qt while things built after pick up the new. Did I understand that correctly ? I'm a little unclear on why that can't be changed with the first stl ABI break; but I guess having Qt's build infrastructure (which hasn't changed) express the stl ABI version (which has) in its SONAME would mean you *only* have to rebuild, without also hacking Qt's build infrastructure to modify the SONAME - which is why different distros would end up with different SONAMEs, because each hacks that its own way. So, once Qt contains any stl in its ABI, it would be courteous to distros to incorporate the stl ABI version in the Qt SONAME, so that any stl ABI break requires *only* a recompile of Qt and any other packages directly affected by the stl ABI break, rather than propagating to all packages. I'm a little unclear on why that won't still be all packages; can you elaborate ? Thiago Macieira (23 March 2017 20:50) > Understood, but that's not Qt's problem. If libc or libstdc++ cause a > BC break, it's their responsibility to update the SONAME. If they > don't, you (Debian) get to complain to them. If my guess above is near the mark, an update to stl's SONAME won't help us here. Qt's SONAME would also need to change when stl's ABI breaks. > Either way, the benefit of keeping Qt immune to those breaks is so > small to the point that it's not worth it. As long as stl ABI breaks are rare, yes. The tricky part is that everyone makes mistakes ... >>> > Oh, and if some non-other Qt api is exposed it should also become >>> > part of the SONAME. >>> >>> Again, why? We've exposed C and Xlib API for years and have never >>> had "X11" in the name (or "xcb" now). My understanding was that the only exposure we give to that is passing an opaque handle through, from the library to our client. As long as the client is only ever using it to pass back to the same library, without looking inside the black box - and as long as the opaque type hasn't changed (void* was the example ISTR) - this isn't really an ABI dependency. The issue would arise if we, or the client, were to look inside that opaque type, possibly by calling some inline of the library; but I doubt this happens for the types involved. They come from the X or xcb library and travel back to it; any given run-time process only deals with one version of that library, so all's well. That would even imply a need to link Qt against the library, of course; so I suspect my understanding is incomplete ... how *are* we using X/xcb types ? >> Maybe because they never broke? At least in the time I've been >> maintaining Qt in Debian we have never encountered an issue with >> this. This is from the last Qt 4 releases before Qt5. > > Right and that's the entire point: there are some libraries (a > whitelist) whose types we'll have in our public ABI, so Qt's ABI is > then dependent on theirs. We'll only add libraries that have a good > track record of keeping BC. Surely Qt's API can use any library-derived type that's opaque (void*, most obviously, via whatever typedefs), as long as the library has no inlines that unwrap it. That means the client's only possible use of it is to pass it back to the same library we got it from, with no risk of incompatibility. Eddy (not an expert on shared libraries). From rjvbertin at gmail.com Fri Mar 24 10:46:40 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 24 Mar 2017 10:46:40 +0100 Subject: [Development] QMenu::addSection() across platforms Message-ID: <1978617.p3R9njJL0h@bola> Hi, I continue to find it strange that Qt would introduce a convenience method to add labelled sections to menus if that feature isn't available on all platforms. I understand there are limitations to what native menus in native menubars can show but not the step from that fact to an official attitude "just don't use QMenu::addSection on those platforms". Yet that's exactly how a bug report I filed on this topic was closed (a while back). I read that as "just don't use QMenu::addSection in cross-platform code", which in practice translates to "just don't use QMenu::addSection" - at all. Is this still the official stance or has it been mellowed with time and insight that organising menus with labelled sections can be useful in applications with a rich (complex) GUI? Again, I can understand that "texted separators" created with something like `menu->addSeparator()->setText("this may be a section label")` don't have the same appearance everywhere. A dedicated method `menu->addSection("This will be a section")` suggests otherwise, though. I've been playing around with the code after I discovered the existence of the corresponding style hint and am testing a patch that attempts to provide a reasonable rendition of a "texted separator": if SH_Menu_SupportsSections is false, use the emulation else: if the menu belongs to a native menubar on Mac (or MS Windows?), use emulation else texted separators should work just fine. IOW, on Mac emulation is only necessary when using the native widget style or else for menus attached to the native menubar. Emulation is really quite simple: if the above check indicates it's required, add an additional regular but deactivated QAction to the menu holding the section text before adding the texted separator action. It would be nice if there were a way to centre the text of the disabled menu item but the result is close enough to a style that renders the section entry with underlined text. In either case it's up to the application to use a section text label that doesn't make the user think the menu entry should actually do something. This emulation is done when the menu is constructed so the overhead associated with determining if the menu belongs to a native menubar should be acceptable. R. PS: am I right that even the Macintosh style could actually support texted separators in context menus and nonnative-menubar-menus? From jani.heikkinen at qt.io Fri Mar 24 11:21:04 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 24 Mar 2017 10:21:04 +0000 Subject: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug In-Reply-To: References: <1676263.q5QZILVYxz@tjmaciei-mobl1>, Message-ID: Latest Qt 5.9.0 beta snapshot src tarballs here: http://download.qt.io/snapshots/qt/5.9/5.9.0-beta/1489997285/ (or directly from online installer) br, Jani ________________________________________ From: Development on behalf of Ed Leaver Sent: Thursday, March 23, 2017 10:57 PM To: development at qt-project.org Subject: Re: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug On 03/23/2017 01:43 PM, Thiago Macieira wrote: On quinta-feira, 23 de março de 2017 10:59:25 PDT Ed Leaver wrote: will attempt gcc-4.8.2 -no-std=c++11 in the next few days. If you think this worthwhile, have you a Qt-5.9.0-beta source tarball? You can't turn C++11 off since 5.7.0. Thanks. Saved me some time and confusion. I didn't personally wish to turn off C++11 anyway. I'll try 5.7.0 then against gcc-4.8.2, but am still interested in a 5.9.0-beta source tarball to test with gcc-5.4.0 and later, if such beta tarball becomes available. From edward.welbourne at qt.io Fri Mar 24 11:34:37 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 24 Mar 2017 10:34:37 +0000 Subject: [Development] QList In-Reply-To: References: <2884720.dci7Rcneo1@tjmaciei-mobl1> <201703220927.55011.marc.mutz@kdab.com> <3839800.EQHgOQLkYg@tjmaciei-mobl1>, Message-ID: Marc Mutz (23 March 2017 20:41) > Do I need to mention QPolygon and what pain it's inheritance from > QVector has caused? (FTR: cf. end of qvector.h and > qvector_msvc.cpp). well, I - for one - can only see a minor problem; so, since you *have* mentioned it, perhaps you could elaborate ? I hadn't realised QVector wasn't public - I can see how that would be an argument for the inheritance to be private. Is there more to the problem than that ? You make it sound a bigger deal than anything I can see in the source - so please educate me, Eddy. From Kai.Koehne at qt.io Fri Mar 24 12:24:30 2017 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 24 Mar 2017 11:24:30 +0000 Subject: [Development] QUIP-7: qt_attribution.json File Format Message-ID: Hi, This is a heads-up that I've moved parts of QUIP-4 (Third-Party Components in Qt) a while ago into a separate Implementation QUIP. The details about the qt_attribution.json file format are now described in proposed QUIP-7: https://codereview.qt-project.org/#/c/147271/ Comments welcome, both for the document as well as the format itself :) Kai -- Kai Köhne, Senior Manager R&D | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Kai.Koehne at qt.io Fri Mar 24 12:27:29 2017 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 24 Mar 2017 11:27:29 +0000 Subject: [Development] QUIP-7: qt_attribution.json File Format In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Kai Koehne > Sent: Friday, March 24, 2017 12:25 PM > To: development at qt-project.org > Subject: [Development] QUIP-7: qt_attribution.json File Format > > Hi, > > This is a heads-up that I've moved parts of QUIP-4 (Third-Party Components > in Qt) a while ago into a separate Implementation QUIP. The details about > the qt_attribution.json file format are now described in proposed QUIP-7: > > https://codereview.qt-project.org/#/c/147271/ Copy/paste error. Correct link is https://codereview.qt-project.org/#/c/185792/ Sorry about this Kai From marc.mutz at kdab.com Fri Mar 24 13:31:32 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 24 Mar 2017 13:31:32 +0100 Subject: [Development] QList In-Reply-To: References: Message-ID: <201703241331.32661.marc.mutz@kdab.com> On Friday 24 March 2017 11:34:37 Edward Welbourne wrote: > Marc Mutz (23 March 2017 20:41) > > > Do I need to mention QPolygon and what pain it's inheritance from > > QVector has caused? (FTR: cf. end of qvector.h and > > qvector_msvc.cpp). > > well, I - for one - can only see a minor problem; so, since you *have* > mentioned it, perhaps you could elaborate ? I hadn't realised QVector > wasn't public - I can see how that would be an argument for the > inheritance to be private. Is there more to the problem than that ? > You make it sound a bigger deal than anything I can see in the source - > so please educate me, Well, where should I start? There are two principles that interact to cause all kinds of mayhem, both of them on Windows: 1. When a class is exported, all of its members are exported. That includes the base class' members, regsardless of whether they were exported themselves or not. 2. When an inline function is exported (by itself or via a class-level export), MSVC calls the copy in the DLL. I don't know whether it places a copy in the user's executable at all. You can prevent this behaviour by marking each such function with Q_ALWAYS_INLINE. (2) means we can't change signatures of exported inline functions, because that would be BiC on Windows/Debug. On all other platforms, incl. Windows/Release, renaming, removing, changing the signature of, an inline function, exported or not, is always BC. It may be SiC, but it's always BC. We have many use-cases that assume that inline functions do not form part of the ABI: a. QVector and other container change the signature of begin() etc to implement QT_STRICT_ITERATORS. As a consequence, QT_STRICT_ITERATORS fails for (at least) QXmlStreamAttributes, inheriting QVector, because only one of the two overloaded functions gets exported while the other one is not. You may disregard this as a container-only thing, but it's far more widespread: b. We also assume we can #if Q_COMPILER away functions as long as they are inline. You see where this is going? Once MS actually keeps BC themselves, and afaiu, they plan to do so for 2015 -> 2017, this will cause BiC in all exported classes whenever 2015 lacks a feature that 2017 provides. I don't know why Thiago thinks these reasons are not worth stopping exporting non-polymorphic classes for, but I'm absolutely convinced that exporting only non-inline functions in such classes is the only correct way to deal with the Microsoft platform. Non-polymophic classes should decide what they want to be: I. if they want to be pimpl'ed, they should have most functions out-of-line. In this case, it's ok to export the whole class, but all inline functions should have to be marked as Q_ALWAYS_INLINE from the outset. II. if they want to be thin abstractions, most functions should be inline. The class should not be exported, only out-of-line functions should be. To prevent inheriting such classes, thereby exporting their inline functions, such classes should be agressively marked as final. Polymophic classes should follow the rules of (I) (class-level exporting them is required here) plus have all their virtuals (incl. esp. their dtor) defined out-of-line. HTH, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Fri Mar 24 16:34:17 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 24 Mar 2017 08:34:17 -0700 Subject: [Development] QList In-Reply-To: <201703240934.18483.marc.mutz@kdab.com> References: <35533789.cmIqBDbaWG@tjmaciei-mobl1> <201703240934.18483.marc.mutz@kdab.com> Message-ID: <2470039.AWbPmsyYGb@tjmaciei-mobl1> Em sexta-feira, 24 de março de 2017, às 01:34:18 PDT, Marc Mutz escreveu: > I listed _the_ three use-cases where inheritance is the tool of choice: > > 1. modelling is-a > 2. inheriting to reuse > 3. reimplementing virtual functions > > If your use-case is not one of the three, then inheritance is not the right > tool. > > Clearly, by now, it's neither (1) nor (3). So if anything, it needs to be > (2). > > And I'm arguing that it's not (2), either, because you can only re-use a > subset of QStringView API, and need to wrap the other half anyway. (2) is > really only interesting for pure OO languages with no concept of free > functions. In C++, we have free functions. Marc, philosophical question then: Are you of the opinion that private inheritance has no purpose and should never be used? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Mar 24 16:50:06 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 24 Mar 2017 08:50:06 -0700 Subject: [Development] QList In-Reply-To: <201703241331.32661.marc.mutz@kdab.com> References: <201703241331.32661.marc.mutz@kdab.com> Message-ID: <5824300.pcO1R46oQ0@tjmaciei-mobl1> Em sexta-feira, 24 de março de 2017, às 05:31:32 PDT, Marc Mutz escreveu: > Well, where should I start? There are two principles that interact to cause > all kinds of mayhem, both of them on Windows: > > 1. When a class is exported, all of its members are exported. That includes > the base class' members, regsardless of whether they were exported > themselves or not. > 2. When an inline function is exported (by itself or via a class-level > export), MSVC calls the copy in the DLL. I don't know whether it places a > copy in the user's executable at all. You can prevent this behaviour by > marking each such function with Q_ALWAYS_INLINE. Note: you may force a local copy with Q_ALWAYS_INLINE, but that does not stop the DLL from exporting the function in the first place. > (2) means we can't change signatures of exported inline functions, because > that would be BiC on Windows/Debug. On all other platforms, incl. > Windows/Release, renaming, removing, changing the signature of, an inline > function, exported or not, is always BC. It may be SiC, but it's always BC. That still has exceptions, like inlines that have statics inside or if the address of the inline is taken. So we should still apply regular our rules for BC to those inline functions, with the extra requirement that "it must be ok for old code to call the old version". So inlines are actually harder on BC than non-inlines... > We have many use-cases that assume that inline functions do not form part of > the ABI: > > a. QVector and other container change the signature of begin() etc to > implement QT_STRICT_ITERATORS. As a consequence, QT_STRICT_ITERATORS > fails for (at least) QXmlStreamAttributes, inheriting QVector, because only > one of the two overloaded functions gets exported while the other one is > not. > > You may disregard this as a container-only thing, but it's far more > widespread: > > b. We also assume we can #if Q_COMPILER away functions as long as they are > inline. You see where this is going? Once MS actually keeps BC > themselves, and afaiu, they plan to do so for 2015 -> 2017, this will cause > BiC in all exported classes whenever 2015 lacks a feature that 2017 > provides. > > I don't know why Thiago thinks these reasons are not worth stopping > exporting non-polymorphic classes for, but I'm absolutely convinced that > exporting only non-inline functions in such classes is the only correct way > to deal with the Microsoft platform. Because (1) was very restricted and (2) hadn't happened until now. You're probably right: all the constexpr (thus inline) functions in our exported classes are not present in the MSVC 2015 binaries. So if you compile against MSVC 2017, the compiler will expect them to be there and the link will fail. We need to verify this is the case. There's an easy way out: provide an MSVC 2017 binary, so people don't try to mix. We need to reevaluate what to do. I still think the export-each-function-in- the-class is mighty ugly and should be avoided. > Non-polymophic classes should decide what they want to be: > > I. if they want to be pimpl'ed, they should have most functions out-of-line. > In this case, it's ok to export the whole class, but all inline functions > should have to be marked as Q_ALWAYS_INLINE from the outset. I disagree with that on style purposes and in the causing of inlining when the compiler didn't really want it (even in release mode). But as I said above: need reevaluation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Mar 24 17:18:05 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 24 Mar 2017 17:18:05 +0100 Subject: [Development] QList In-Reply-To: <2470039.AWbPmsyYGb@tjmaciei-mobl1> References: <201703240934.18483.marc.mutz@kdab.com> <2470039.AWbPmsyYGb@tjmaciei-mobl1> Message-ID: <201703241718.05520.marc.mutz@kdab.com> On Friday 24 March 2017 16:34:17 Thiago Macieira wrote: > Em sexta-feira, 24 de março de 2017, às 01:34:18 PDT, Marc Mutz escreveu: > > I listed _the_ three use-cases where inheritance is the tool of choice: > > > > 1. modelling is-a > > 2. inheriting to reuse > > 3. reimplementing virtual functions > > > > If your use-case is not one of the three, then inheritance is not the > > right tool. > > > > Clearly, by now, it's neither (1) nor (3). So if anything, it needs to be > > (2). > > > > And I'm arguing that it's not (2), either, because you can only re-use a > > subset of QStringView API, and need to wrap the other half anyway. (2) is > > really only interesting for pure OO languages with no concept of free > > functions. In C++, we have free functions. > > Marc, philosophical question then: > > Are you of the opinion that private inheritance has no purpose and should > never be used? No, and if you look at code I have written over the years, you will see that I do use it. One thing I've looked into in the past is this: Q6Polygon should inherit a Q6VectorBase that also Q6Vector inherits. This will allow easy specialisation of QVector by inheriting QBasicVector. I can even think of a similar pattern for QStringView/QLatin1(String| View)/QUtf8(String|View), though I guess that just enable_if'ing functions out of the primate template will do the job just fine, so the three classes would be mere typedefs of the template. But in these cases, we're reusing next to 100% of the functionality, by way of lots of using Base::foo; This is not the case for QString : QStringView. They're completely unrelated, because one if owning and the other is non- owning. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From corentin.jabot at gmail.com Fri Mar 24 17:25:34 2017 From: corentin.jabot at gmail.com (Corentin) Date: Fri, 24 Mar 2017 16:25:34 +0000 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: <18416166.MC6PJ1Ml06@maurice> References: <18416166.MC6PJ1Ml06@maurice> Message-ID: Is std::algo(std::begin(container), std::end(container) ... ) troublesome enough that it warrants a wrapper ? I have a few concerns: * There is a large momentum behind the range proposal, and, if it wont be in the standard before 2-4 years, I would expect the TS to be usable long before that. For simple iterator abstractions like sort, find, etc, range-v3 is certainly already pretty stable from an api standpoint. * C++17 bring parallel version of some algorithms. I haven't look what the requirements for a containers are to be compatible with those parallel algorithms are, but I would prefer Qt to focus on that. * I'm afraid it won't be a popular opinion, but I wouldn't mind seing constBegin() / constEnd() deprecated, as they are redundant Your last example is simplified by the Library Fundamentals TS https://rawgit.com/cplusplus/fundamentals-ts/v2/fundamentals-ts.html#container.erasure erase_if(std::begin(myList), std::end(myList), [&](const auto &elem) { elem.field > someValue; }); If we fast forward to say, 5 years in the future, people will be confused as to whether use std2::sort or Qt::sort (and if Qt::sort do not relies on concept, it won't be as trivial to use ) If there is an immediate urgent need, a solution would be to have an api that matches as close as possible the range TS, so that the migration path can be as simple as changing "Qt" by "std2" Le jeu. 23 mars 2017 à 08:32, Olivier Goffart a écrit : > Hi everyone, > > I have been wondering if we should enhance Qt container with member > functions > to help using some of the standard algorithm. > a peace of code is better than many words. We would be able to do: > > myList.sort(); > //or > myList.sort([](auto &a, auto &b){ return a.member < b.member; }); > > if (myList.contains([&value](const auto &elem){ return elem.id == value; > })) > doSomething(); > > myList.removeIf([&](const auto &elem) { elem.field > someValue; }) > > > And these are a tad more convenient than using the standard library > directly. > Compare to: > myList.erase(std::remove_if(myList.begin(), myList.end(), > [&](const auto &elem) { elem.field > someValue; }), > myList.end()); > > Of course, myList can be a QList, a QVector, or a QVarLenghtArray > > Here is an overview in how this could be implemented, should we want this: > https://codereview.qt-project.org/#/c/189313/ > > > Anyway, before I continue working on this patch, I want to know if this is > even something what the Qt Project wants. > > The reason we would want it are obvious: convenience. > > In the mean time, the standard is working on the so called range library. > So > in C++20, you could maybe just write std::sort(myList). > But that's in the far future, and I want to be able to use it now. > There are already convenient range libraries that makes things convenient > available on github, but that's another dependency and the compatibility > guarantee are not the same. > > > The reason we would not want this is because this makes our containers too > convenient. The implementation of QVector is inferior to the one of > std::vector. (for example, it cannot contains move-only types). > Right now, it is quite easy to replace QVector by std::vector. But adding > nice > feature to QVector may mean a reason to keep QVector longer in Qt6 instead > of > changing to standard containers. > > Marc already expressed his opinion on the gerrit change, pointing out that > we > deprecated qSort and the qt algorithm for a reason: the quality of the std > algorithm was better than the naive implementation in Qt. However this is > just > a helper around the std algorithm implementation. > > > Why did we not added these function already in Qt 4.0? I was not there > yet, > but I believe this might have been for technical reason: MSVC 6 was still > supported until Qt 4.5, which mans no template member functions. > Also sort needs an operator<, and non-template function might be > instantiated > even if not used. > > So with this mail I would like to know what you think. If you think this > is a > good idea or a terrible one. > > > Once we agreed the general idea is good, we can go into the details of the > API > or implementation. > > On this WIP patch, I only took the algorithm that were most used within Qt > and > QtCreator. I realize that QtCreator already has helper functions: > https://code.woboq.org/qt5/qt-creator/src/libs/utils/algorithm.h.html > That's I think one proof that shows that this would be useful. > > I am wondering if findIf shoud return a pointer or an iterator. > Returning a pointer allow things like > if (auto *elem = myContainer.findIf([&](const auto &elem) > { return elem.foo == bar; })) > elem->plop = myPlop; > > But does not work well if you want to find-then-remove: > auto it = std::find(myContainer.begin(), myContainer.end(), > [&](const auto &elem) { return elem.foo == bar; }); > if (it != myContainer.end()) { > myResult = *it; > myContainer.erase(it); // not possible if 'it' was a pointer > } > > So I'm afraid there will be much discussions and bike-shedding > > Regards > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - > https://code.woboq.org > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Fri Mar 24 19:00:57 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 24 Mar 2017 19:00:57 +0100 Subject: [Development] RFC: Containers member functions for algorithm References: <18416166.MC6PJ1Ml06@maurice> <63afe00c-22c0-3404-6145-03f295c4a37e@qt.io> Message-ID: Michael Winkelmann wrote: > The reason why STL is using free function is because it separates data > structures (aka containers) and algorithms. > A bad example what happens if you dont separate can be seen here: > https://www.imagemagick.org/api/Magick++/Image_8h_source.html > > ...and your data structure will be bloated with member functions. Why is that bad? It is convenient and object-oriented. Moving everything to freestanding functions goes against the principles of OOP. That said, even freestanding functions would be better than the current boilerplate myContainer.begin(), myContainer.end() copypasta. Kevin Kofler From kevin.kofler at chello.at Fri Mar 24 19:25:54 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 24 Mar 2017 19:25:54 +0100 Subject: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug References: <1676263.q5QZILVYxz@tjmaciei-mobl1> Message-ID: Ed Leaver wrote: > I'll try 5.7.0 then against gcc-4.8.2 5.7.0 is actually the first release that will NOT work without C++11. You will have to try 5.6.x instead. Kevin Kofler From thiago.macieira at intel.com Fri Mar 24 20:55:43 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 24 Mar 2017 12:55:43 -0700 Subject: [Development] QList In-Reply-To: <201703241718.05520.marc.mutz@kdab.com> References: <2470039.AWbPmsyYGb@tjmaciei-mobl1> <201703241718.05520.marc.mutz@kdab.com> Message-ID: <5481897.66cYp8QahV@tjmaciei-mobl1> Em sexta-feira, 24 de março de 2017, às 09:18:05 PDT, Marc Mutz escreveu: > > Are you of the opinion that private inheritance has no purpose and should > > never be used? > > No, and if you look at code I have written over the years, you will see that > I do use it. > > One thing I've looked into in the past is this: Q6Polygon should inherit a > Q6VectorBase that also Q6Vector inherits. This will allow > easy specialisation of QVector by inheriting QBasicVector. Can you elaborate on your thinking? What's QBasicVector and what's QVector? In my tree, I have QVector deriving from QGenericArray only because at the time we were considering doing QList still be a pointer array if sizeof(T) > 32. > I can even think of a similar pattern for QStringView/QLatin1(String| > View)/QUtf8(String|View), though I guess that just enable_if'ing functions > out of the primate template will do the job just fine, so the three classes > would be mere typedefs of the template. > > But in these cases, we're reusing next to 100% of the functionality, by way > of lots of using Base::foo; This is not the case for QString : QStringView. > They're completely unrelated, because one if owning and the other is non- > owning. I still disagree. Yes, there's a difference in ownership, but I don't see that as a deal-breaker. In fact, I see that as a plus: that's why we derive, to add functionality, like owning. And like I said, every QString is a view to itself and the pure inspection functions like indexOf() and contains() are exactly the same. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Fri Mar 24 22:33:59 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 24 Mar 2017 22:33:59 +0100 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: References: <18416166.MC6PJ1Ml06@maurice> Message-ID: <20170324213359.GA31525@klara.mpi.htwm.de> On Fri, Mar 24, 2017 at 04:25:34PM +0000, Corentin wrote: > Is std::algo(std::begin(container), std::end(container) ... ) troublesome > enough that it warrants a wrapper ? Yes. 1. It is more to read, and more to verify during reading, e.g. that bother 'container' are the same. This typically implies that 'container' is just a simple identifier for a local variable (i.e. usuall an extra line for a definition) or a member of the current object (rare). Even seeing std::algo(std::begin(foo), std::end(foo) ... ) *verbatim* with a plain 'foo' does not guarantee that both 'foo' refer to the same container, i.e. potentially needs verification when bug hunting. For std::algo(std::begin(foo()), std::end(foo()) ... ) chances are high that it is wrong. Except when it isn't. But for that you need to consult the declaration, and even possibly the implementation of 'foo'. 2. It more to type. std::algo(std::begin(container), std::end(container) ... ) vs foo::algo(container, ... ) Depending on your project's coding style there are additional complications, e.g. that the ~55 chars of the first are 'a lot' in a 80 char-per-line setup. > Your last example is simplified by the Library Fundamentals TS > https://rawgit.com/cplusplus/fundamentals-ts/v2/fundamentals-ts.html#container.erasure > erase_if(std::begin(myList), std::end(myList), [&](const auto &elem) { > elem.field > someValue; }); 100 chars, vs 70 chars for a no-begin-end-cluttered erase_if(myList, [&](const auto &elem) { elem.field > someValue; }); and some hope that it going from 'myList' to 'myList()' is really just two chars change. Not Nice (TM). Andre' From chgans at gna.org Sat Mar 25 00:24:57 2017 From: chgans at gna.org (Ch'Gans) Date: Sat, 25 Mar 2017 12:24:57 +1300 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: References: <18416166.MC6PJ1Ml06@maurice> <63afe00c-22c0-3404-6145-03f295c4a37e@qt.io> Message-ID: On 25 March 2017 at 07:00, Kevin Kofler wrote: > Michael Winkelmann wrote: >> The reason why STL is using free function is because it separates data >> structures (aka containers) and algorithms. >> A bad example what happens if you dont separate can be seen here: >> https://www.imagemagick.org/api/Magick++/Image_8h_source.html >> >> ...and your data structure will be bloated with member functions. > > Why is that bad? It is convenient and object-oriented. Moving everything to > freestanding functions goes against the principles of OOP. "OO was hip in the 80s and 90s, but its time we moved beyond!". >From http://www.boost.org/doc/libs/1_63_0/libs/graph/doc/faq.html item 3, last paragraph. I'm not advocating for free functions, i really hate them. I have been working with boost graph recently and find this technique awful to write, awful to read and counter intuitive. I hope Qt won't become like boost. Chris > > That said, even freestanding functions would be better than the current > boilerplate myContainer.begin(), myContainer.end() copypasta. > > Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Sat Mar 25 08:57:57 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 25 Mar 2017 08:57:57 +0100 Subject: [Development] QList In-Reply-To: <5481897.66cYp8QahV@tjmaciei-mobl1> References: <2470039.AWbPmsyYGb@tjmaciei-mobl1> <201703241718.05520.marc.mutz@kdab.com> <5481897.66cYp8QahV@tjmaciei-mobl1> Message-ID: On 2017-03-24 20:55, Thiago Macieira wrote: > Em sexta-feira, 24 de março de 2017, às 09:18:05 PDT, Marc Mutz > escreveu: >> > Are you of the opinion that private inheritance has no purpose and should >> > never be used? >> >> No, and if you look at code I have written over the years, you will >> see that >> I do use it. >> >> One thing I've looked into in the past is this: Q6Polygon should >> inherit a >> Q6VectorBase that also Q6Vector inherits. This will >> allow >> easy specialisation of QVector by inheriting QBasicVector> void*>. > > Can you elaborate on your thinking? What's QBasicVector and what's > QVector? QBasicVector (or QVectorBase, or ...) is QVector with protection against using it as-is (e.g. protected dtor). QVector inherits QBasicVector to lift the restriction. This inheritance may even be public to avoid lots of using QBasicVector::foo; This is ok, because QBasicVector is not usable as-is, but I'd still make it private, because when you start to inherit to specialise (QVector : QBasicVector), you don't want the void* methods to leak. So, if you absolutely are set on inheritance, then use the same pattern. But I don't see this here. None of the points that makes this a good idea for QVector (or QVLA) pertains to QString: we don't need to fight template bloat, we don't have multiple classes inheriting QStringView... Thanks, Marc From thiago.macieira at intel.com Sat Mar 25 16:29:09 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 25 Mar 2017 08:29:09 -0700 Subject: [Development] QList In-Reply-To: References: <5481897.66cYp8QahV@tjmaciei-mobl1> Message-ID: <2143999.qk5xfsi61R@tjmaciei-mobl1> On sábado, 25 de março de 2017 00:57:57 PDT Marc Mutz wrote: > On 2017-03-24 20:55, Thiago Macieira wrote: > > Em sexta-feira, 24 de março de 2017, às 09:18:05 PDT, Marc Mutz > > > > escreveu: > >> > Are you of the opinion that private inheritance has no purpose and > >> > should > >> > never be used? > >> > >> No, and if you look at code I have written over the years, you will > >> see that > >> I do use it. > >> > >> One thing I've looked into in the past is this: Q6Polygon should > >> inherit a > >> Q6VectorBase that also Q6Vector inherits. This will > >> allow > >> easy specialisation of QVector by inheriting QBasicVector >> void*>. > > > > Can you elaborate on your thinking? What's QBasicVector and what's > > QVector? > > QBasicVector (or QVectorBase, or ...) is QVector with protection against > using it as-is (e.g. protected dtor). QVector inherits QBasicVector to > lift the restriction. This inheritance may even be public to avoid lots > of using QBasicVector::foo; This is ok, because QBasicVector is not > usable as-is, but I'd still make it private, because when you start to > inherit to specialise (QVector : QBasicVector), you > don't want the void* methods to leak. > > So, if you absolutely are set on inheritance, then use the same pattern. > But I don't see this here. None of the points that makes this a good > idea for QVector (or QVLA) pertains to QString: we don't need to fight > template bloat, we don't have multiple classes inheriting QStringView... And what are the points that make QBasicVector good? If QBasicVector is not usable as-is, then it must be useful because it's sharing code between QVector and something else. What is that something else? Note that I think we should change QPolygon to stop inheriting from QVector in the first place. QPolygon is not a QVector. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Martin.Smith at qt.io Sat Mar 25 17:11:48 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Sat, 25 Mar 2017 16:11:48 +0000 Subject: [Development] QList In-Reply-To: <2143999.qk5xfsi61R@tjmaciei-mobl1> References: <5481897.66cYp8QahV@tjmaciei-mobl1> , <2143999.qk5xfsi61R@tjmaciei-mobl1> Message-ID: >Note that I think we should change QPolygon to stop inheriting from QVector in >the first place. QPolygon is not a QVector. But then a vector is not a collection. ________________________________ From: Development on behalf of Thiago Macieira Sent: Saturday, March 25, 2017 4:29:09 PM To: development at qt-project.org Subject: Re: [Development] QList On sábado, 25 de março de 2017 00:57:57 PDT Marc Mutz wrote: > On 2017-03-24 20:55, Thiago Macieira wrote: > > Em sexta-feira, 24 de março de 2017, às 09:18:05 PDT, Marc Mutz > > > > escreveu: > >> > Are you of the opinion that private inheritance has no purpose and > >> > should > >> > never be used? > >> > >> No, and if you look at code I have written over the years, you will > >> see that > >> I do use it. > >> > >> One thing I've looked into in the past is this: Q6Polygon should > >> inherit a > >> Q6VectorBase that also Q6Vector inherits. This will > >> allow > >> easy specialisation of QVector by inheriting QBasicVector >> void*>. > > > > Can you elaborate on your thinking? What's QBasicVector and what's > > QVector? > > QBasicVector (or QVectorBase, or ...) is QVector with protection against > using it as-is (e.g. protected dtor). QVector inherits QBasicVector to > lift the restriction. This inheritance may even be public to avoid lots > of using QBasicVector::foo; This is ok, because QBasicVector is not > usable as-is, but I'd still make it private, because when you start to > inherit to specialise (QVector : QBasicVector), you > don't want the void* methods to leak. > > So, if you absolutely are set on inheritance, then use the same pattern. > But I don't see this here. None of the points that makes this a good > idea for QVector (or QVLA) pertains to QString: we don't need to fight > template bloat, we don't have multiple classes inheriting QStringView... And what are the points that make QBasicVector good? If QBasicVector is not usable as-is, then it must be useful because it's sharing code between QVector and something else. What is that something else? Note that I think we should change QPolygon to stop inheriting from QVector in the first place. QPolygon is not a QVector. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Sat Mar 25 18:22:22 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 25 Mar 2017 18:22:22 +0100 Subject: [Development] QList In-Reply-To: <2143999.qk5xfsi61R@tjmaciei-mobl1> References: <2143999.qk5xfsi61R@tjmaciei-mobl1> Message-ID: <201703251822.22846.marc.mutz@kdab.com> On Saturday 25 March 2017 16:29:09 Thiago Macieira wrote: > On sábado, 25 de março de 2017 00:57:57 PDT Marc Mutz wrote: > > On 2017-03-24 20:55, Thiago Macieira wrote: > > > Em sexta-feira, 24 de março de 2017, às 09:18:05 PDT, Marc Mutz > > > escreveu: > > >> > Are you of the opinion that private inheritance has no purpose and > > >> > should > > >> > never be used? > > >> > > >> No, and if you look at code I have written over the years, you will > > >> see that > > >> I do use it. > > >> > > >> One thing I've looked into in the past is this: Q6Polygon should > > >> inherit a > > >> Q6VectorBase that also Q6Vector inherits. This will > > >> allow > > >> easy specialisation of QVector by inheriting QBasicVector > >> void*>. > > > > > > Can you elaborate on your thinking? What's QBasicVector and what's > > > QVector? > > > > QBasicVector (or QVectorBase, or ...) is QVector with protection against > > using it as-is (e.g. protected dtor). QVector inherits QBasicVector to > > lift the restriction. This inheritance may even be public to avoid lots > > of using QBasicVector::foo; This is ok, because QBasicVector is not > > usable as-is, but I'd still make it private, because when you start to > > inherit to specialise (QVector : QBasicVector), you > > don't want the void* methods to leak. > > > > So, if you absolutely are set on inheritance, then use the same pattern. > > But I don't see this here. None of the points that makes this a good > > idea for QVector (or QVLA) pertains to QString: we don't need to fight > > template bloat, we don't have multiple classes inheriting QStringView... > > And what are the points that make QBasicVector good? If QBasicVector is not > usable as-is, then it must be useful because it's sharing code between > QVector and something else. What is that something else? The main idea of QBasicVector is to fight template bloat by e.g. inheriting both QVector and QVector from the same QBasicVector. Likewise, all QVector can inherit QBasicVector. Or all QVector, intergral_type can inherit QBasicVector::Unsigned>, or all QVector, is_enum, from QBasicVector>::Unsigned>, or even QVector, qt_is_refcounted && sizeof(T) == sizeof(void*) : QBasicVector>... You can do this with composition, too. You don't even need QBasicVector. But if you e.g. want to collapse all QV to QV, you need to either manually specialise QV or use SFINAE so the T* case does not match const void*. Then you can aggregate a QV in QV and delegate all functions there. With a separate QBasicVector, however, you don't need that special-casing of const void*, or any of the other basic instantiated types, since the type where you partially specialise is different from the implementation type. You can also generally have QVector _contain_ a QBasicVector, and do the specialisation via a type trait: template class QVector { using underlying_t = typename qvector_choose_underlying_for::type; QBasicVector impl; T* begin() { return reinterpret_cast (const_cast*> (impl.begin())); } // ... } template struct qvector_choose_underlying_for : std::add_const {}; template , bool> = false> struct qvector_choose_underlying_for : qvector_choose_underlying_for> {}; // ... There are lots of options here, too. But if you throw extern templates into the mix, it probably pays off if QVector::reserve() _is_ QBasicVector>::reserve(), meaning inheritance, so that the compiler need not instantiate a delegating function but directly hits the extern template declaration for QBasicVector. I have no idea how that plays with inlining, though. Maybe in the end this also turns into a case for using free functions to control inlining better. I also have not thought this through. But all that said, all this specialisation stuff, all the types that want to inherit QVector because they are some form of collection of things, with no or little constraints added, and all these not-yet-mentioned uses of QBV to implement fast conversion from, say, QPolygon to QVector, even though they are unrelated, these all do not apply to QString. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From giuseppe.dangelo at kdab.com Sat Mar 25 20:08:09 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sat, 25 Mar 2017 20:08:09 +0100 Subject: [Development] QList In-Reply-To: References: <5481897.66cYp8QahV@tjmaciei-mobl1> <2143999.qk5xfsi61R@tjmaciei-mobl1> Message-ID: <008c06bf-9089-47ad-4b7f-1b9d58f3f4e5@kdab.com> Il 25/03/2017 17:11, Martin Smith ha scritto: >>Note that I think we should change QPolygon to stop inheriting from > QVector in > >>the first place. QPolygon is not a QVector. > > > But then a vector is not a collection. So you're saying that since QPolygon is a collection (of points) and QVector is a collection (of anything), then a QPolygon is a QVector? Humans are mammals, whales are mammals, therefore humans are whales? -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Sat Mar 25 22:13:04 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 25 Mar 2017 14:13:04 -0700 Subject: [Development] QList In-Reply-To: <201703251822.22846.marc.mutz@kdab.com> References: <2143999.qk5xfsi61R@tjmaciei-mobl1> <201703251822.22846.marc.mutz@kdab.com> Message-ID: <3194371.dV0YKtOsDz@tjmaciei-mobl1> On sábado, 25 de março de 2017 10:22:22 PDT Marc Mutz wrote: > The main idea of QBasicVector is to fight template bloat by e.g. inheriting > both QVector and QVector from the same QBasicVector. Likewise, > all QVector can inherit QBasicVector. Or all QVector, > intergral_type can inherit QBasicVector::Unsigned>, > or all QVector, is_enum, from > QBasicVector>::Unsigned>, or even > QVector, qt_is_refcounted && sizeof(T) == sizeof(void*) : > QBasicVector>... I see what you mean. Yes, there's some code that can be shared and we should explore doing so. That's what QArrayDataOps is for, BTW: QPodArrayOps should help a lot. But unless we start moving things out-of-line, I don't think we'll reduce template bloat, as almost everything is inlined anyway, regardless of whether it's T* or void*; enum E or std::underlying_type::type, etc. > You can do this with composition, too. You don't even need QBasicVector. But > if you e.g. want to collapse all QV to QV, you need to > either manually specialise QV or use SFINAE so the T* case > does not match const void*. Then you can aggregate a QV in > QV and delegate all functions there. Right. > You can also generally have QVector _contain_ a QBasicVector, and do > the specialisation via a type trait: > > template > class QVector { > using underlying_t = typename qvector_choose_underlying_for::type; > QBasicVector impl; > T* begin() { return reinterpret_cast > (const_cast*> > (impl.begin())); } > // ... > } Worth exploring, but my gut feeling says this will not help with code size, but will hinder maintenance. > I have no idea how that plays with inlining, though. Maybe in the end this > also turns into a case for using free functions to control inlining better. Right. This only reduces code size if we do out-of-line work somewhere. That's why we have QListData, QArrayData, QMapData, etc. That's why Qt 1 had QGList, QGVector and QGArray, even. > But all that said, all this specialisation stuff, all the types that want to > inherit QVector because they are some form of collection of things, with no > or little constraints added, and all these not-yet-mentioned uses of QBV to > implement fast conversion from, say, QPolygon to QVector, even > though they are unrelated, these all do not apply to QString. This won't solve the MSVC problem. The only way to solve the MSVC problem is to stop the inheritance of an exported class from a non-exported (especially template!) one. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Mar 25 22:06:47 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 25 Mar 2017 14:06:47 -0700 Subject: [Development] QList In-Reply-To: <008c06bf-9089-47ad-4b7f-1b9d58f3f4e5@kdab.com> References: <008c06bf-9089-47ad-4b7f-1b9d58f3f4e5@kdab.com> Message-ID: <3214655.5uKiTdW2PH@tjmaciei-mobl1> On sábado, 25 de março de 2017 12:08:09 PDT Giuseppe D'Angelo wrote: > Il 25/03/2017 17:11, Martin Smith ha scritto: > >>Note that I think we should change QPolygon to stop inheriting from > >> > > QVector in > > > >>the first place. QPolygon is not a QVector. > >> > > But then a vector is not a collection. > > So you're saying that since QPolygon is a collection (of points) and > QVector is a collection (of anything), then a QPolygon is a QVector? A vector is a sequential collection of items. A polygon is a sequential collection of points. So a polygon can be a vector of points. But I don't think that it should inherit, since some of the operations that you can do in a vector don't really apply to a polygon. That's unlike QString/ QStringView where all operations apply, even if we have an override that returns something differently. > Humans are mammals, whales are mammals, therefore humans are whales? :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philwave at gmail.com Sat Mar 25 23:23:40 2017 From: philwave at gmail.com (Philippe) Date: Sat, 25 Mar 2017 23:23:40 +0100 Subject: [Development] QList In-Reply-To: <3214655.5uKiTdW2PH@tjmaciei-mobl1> References: <008c06bf-9089-47ad-4b7f-1b9d58f3f4e5@kdab.com> <3214655.5uKiTdW2PH@tjmaciei-mobl1> Message-ID: <20170325232339.737E.6F0322A@gmail.com> > A vector is a sequential collection of items. A polygon is a sequential > collection of points. So a polygon can be a vector of points. > > But I don't think that it should inherit, since some of the operations that > you can do in a vector don't really apply to a polygon. 1) To build a QPolygon, you need to add (often many) points. QVector::reserve() is useful for this. 2) resize(0) is useful too, to preserve the allocated memory. 3) Recently, I had to reverse a polygon, std::reverse was useful,... and this applies to QVector. 4) let me quote the Qt doc, which I think makes sense: A QPolygon object is a QVector. The easiest way to add points to a QPolygon is to use QVector's streaming operator, as illustrated below: QPolygon polygon; polygon << QPoint(10, 20) << QPoint(20, 30); //////// Indeed, as a user of QPolygon, I do see and handle a QPolygon as a vector of points... Philippe From giuseppe.dangelo at kdab.com Sun Mar 26 01:06:24 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sun, 26 Mar 2017 01:06:24 +0100 Subject: [Development] QList In-Reply-To: <20170325232339.737E.6F0322A@gmail.com> References: <008c06bf-9089-47ad-4b7f-1b9d58f3f4e5@kdab.com> <3214655.5uKiTdW2PH@tjmaciei-mobl1> <20170325232339.737E.6F0322A@gmail.com> Message-ID: Il 25/03/2017 23:23, Philippe ha scritto: > Indeed, as a user of QPolygon, I do see and handle a QPolygon as a > vector of points... None of these properties strictly depend on the fact that a QPolygon _is-a_ QVector. (A QPolygon quacks, a QVector quacks, therefore a QPolygon must be a QVector!) -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From philwave at gmail.com Sun Mar 26 08:30:46 2017 From: philwave at gmail.com (Philippe) Date: Sun, 26 Mar 2017 08:30:46 +0200 Subject: [Development] QList In-Reply-To: References: <20170325232339.737E.6F0322A@gmail.com> Message-ID: <20170326083045.7C12.6F0322A@gmail.com> > Il 25/03/2017 23:23, Philippe ha scritto: > > Indeed, as a user of QPolygon, I do see and handle a QPolygon as a > > vector of points... > > None of these properties strictly depend on the fact that a QPolygon > _is-a_ QVector. > For sure, but where is the problem of having QPolygon publicly inheriting from a QVector, since the API of QVector is reusable and useful at times, as mentionned? Why changing something that works well and that is conceptually far from shocking? Not to mention the code breaks a change would cause, here. Philippe From Martin.Smith at qt.io Sun Mar 26 10:50:17 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Sun, 26 Mar 2017 08:50:17 +0000 Subject: [Development] QList In-Reply-To: <3214655.5uKiTdW2PH@tjmaciei-mobl1> References: <008c06bf-9089-47ad-4b7f-1b9d58f3f4e5@kdab.com>, <3214655.5uKiTdW2PH@tjmaciei-mobl1> Message-ID: >A vector is a sequential collection of items. A polygon is a sequential >collection of points. So a polygon can be a vector of points. No, a vector is direction and a length. The name for a sequential collection of items is tuple. ________________________________ From: Development on behalf of Thiago Macieira Sent: Saturday, March 25, 2017 10:06:47 PM To: development at qt-project.org Subject: Re: [Development] QList On sábado, 25 de março de 2017 12:08:09 PDT Giuseppe D'Angelo wrote: > Il 25/03/2017 17:11, Martin Smith ha scritto: > >>Note that I think we should change QPolygon to stop inheriting from > >> > > QVector in > > > >>the first place. QPolygon is not a QVector. > >> > > But then a vector is not a collection. > > So you're saying that since QPolygon is a collection (of points) and > QVector is a collection (of anything), then a QPolygon is a QVector? A vector is a sequential collection of items. A polygon is a sequential collection of points. So a polygon can be a vector of points. But I don't think that it should inherit, since some of the operations that you can do in a vector don't really apply to a polygon. That's unlike QString/ QStringView where all operations apply, even if we have an override that returns something differently. > Humans are mammals, whales are mammals, therefore humans are whales? :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sun Mar 26 20:11:42 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 26 Mar 2017 11:11:42 -0700 Subject: [Development] P0 Mac help needed due to Daylight savings Message-ID: <1688381.QYmccQsrLx@tjmaciei-mobl1> This test began failing today: FAIL! : tst_QLocale::macDefaultLocale() 'timeString.contains(expectedGMTSpecifier) || timeString.contains(expectedGMTSpecifierZeroExtended)' returned FALSE. (timeString `1:02:03 AM GMT+02:00', expectedGMTSpecifier `GMT+3' or `GMT+03') The expectation is correct, since Finland is now in Summer time at GMT+3. Someone on a Mac, please check why it's getting GMT+02. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Mar 26 19:49:39 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 26 Mar 2017 10:49:39 -0700 Subject: [Development] QList In-Reply-To: <20170326083045.7C12.6F0322A@gmail.com> References: <20170325232339.737E.6F0322A@gmail.com> <20170326083045.7C12.6F0322A@gmail.com> Message-ID: <1620641.3g3iHE55I6@tjmaciei-mobl1> Em sábado, 25 de março de 2017, às 23:30:46 PDT, Philippe escreveu: > > Il 25/03/2017 23:23, Philippe ha scritto: > > > Indeed, as a user of QPolygon, I do see and handle a QPolygon as a > > > vector of points... > > > > None of these properties strictly depend on the fact that a QPolygon > > _is-a_ QVector. > > For sure, but where is the problem of having QPolygon publicly > inheriting from a QVector, since the API of QVector is reusable and useful > at times, as mentionned? Why changing something that works well and that > is conceptually far from shocking? The MSVC ABI problem. We get linker errors in some cases. qvector.h still has a "### Qt5" comment: /* ### Qt 5: ### This needs to be removed for next releases of Qt. It is a workaround for vc++ because ### Qt exports QPolygon and QPolygonF that inherit QVector and ### QVector respectively. */ This was most recently touched in commit 39e80062d0cf0c25b456bd89be827e50a6077efa, relating to the Intel compiler on Windows. See http://code.qt.io/cgit/qt/qtbase.git/commit/? id=39e80062d0cf0c25b456bd89be827e50a6077efa -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Sun Mar 26 21:15:53 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sun, 26 Mar 2017 21:15:53 +0200 Subject: [Development] QList In-Reply-To: References: <008c06bf-9089-47ad-4b7f-1b9d58f3f4e5@kdab.com>, <3214655.5uKiTdW2PH@tjmaciei-mobl1> Message-ID: <710d0e9a324012550a1eb69984a8029c@kdab.com> On 2017-03-26 10:50, Martin Smith wrote: [...] > No, a vector is direction and a length. The name for a sequential > collection of items is tuple. If you're into mixing math and CS terms, then no, the second: A vector is an element in a vector space and a tuple is an element of a Cartesian Product over (generally) unstructured sets. Yes, using vector for an array type was not Stepanov's best choice of terms (he says so himself), but what you're doing is like arguing that "debt" should be spelled "det". Yes, it should. No, it isn't. :) Thanks, Marc From Martin.Smith at qt.io Sun Mar 26 22:53:59 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Sun, 26 Mar 2017 20:53:59 +0000 Subject: [Development] QList In-Reply-To: <710d0e9a324012550a1eb69984a8029c@kdab.com> References: <008c06bf-9089-47ad-4b7f-1b9d58f3f4e5@kdab.com>, <3214655.5uKiTdW2PH@tjmaciei-mobl1> , <710d0e9a324012550a1eb69984a8029c@kdab.com> Message-ID: >Yes, using vector for an array type was not Stepanov's best choice of >terms (he says so himself), but what you're doing is like arguing that >"debt" should be spelled "det". Yes, it should. No, it isn't. :) I disagree, but if we have accepted that a vector is a collection, then a polygon is a vector. Or it at least has a vector. ________________________________ From: Development on behalf of Marc Mutz Sent: Sunday, March 26, 2017 9:15:53 PM To: development at qt-project.org Subject: Re: [Development] QList On 2017-03-26 10:50, Martin Smith wrote: [...] > No, a vector is direction and a length. The name for a sequential > collection of items is tuple. If you're into mixing math and CS terms, then no, the second: A vector is an element in a vector space and a tuple is an element of a Cartesian Product over (generally) unstructured sets. Yes, using vector for an array type was not Stepanov's best choice of terms (he says so himself), but what you're doing is like arguing that "debt" should be spelled "det". Yes, it should. No, it isn't. :) Thanks, Marc _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuel.gaist at edeltech.ch Mon Mar 27 01:02:15 2017 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Mon, 27 Mar 2017 01:02:15 +0200 Subject: [Development] P0 Mac help needed due to Daylight savings In-Reply-To: <1688381.QYmccQsrLx@tjmaciei-mobl1> References: <1688381.QYmccQsrLx@tjmaciei-mobl1> Message-ID: <0F2D5064-9F4B-4A6C-B94D-8997B49E9E3B@edeltech.ch> > On 26 Mar 2017, at 20:11, Thiago Macieira wrote: > > This test began failing today: > > FAIL! : tst_QLocale::macDefaultLocale() > 'timeString.contains(expectedGMTSpecifier) || > timeString.contains(expectedGMTSpecifierZeroExtended)' returned FALSE. > (timeString `1:02:03 AM GMT+02:00', expectedGMTSpecifier `GMT+3' or `GMT+03') > > The expectation is correct, since Finland is now in Summer time at GMT+3. > Someone on a Mac, please check why it's getting GMT+02. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Hi, Likely a “time propagation” problem. Switzerland changed also in the night of Saturday to Sunday. I have checked that the test failed while I was starting to look into the macOS specific code, midnight passed and then test started to succeed again. I did a quick and rough check using NSCalendar in place of CFGregorianDate and the result was the same, the update to the timezone was only done once march 27 started. Before that, GMT+1 was returned. Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From rolland at ghs.com Mon Mar 27 07:03:25 2017 From: rolland at ghs.com (Rolland Dudemaine) Date: Mon, 27 Mar 2017 05:03:25 +0000 Subject: [Development] P0 Mac help needed due to Daylight savings Message-ID: <7d917157-ea87-4159-8cf7-d8fcd1712d48@ghs.com> Daylight savings are not done at midnight, but at 2am. See https://en.m.wikipedia.org/wiki/Daylight_saving_time Seems like Mac is correct, and the test should not fail. --Rolland ________________________________ De: Thiago Macieira Envoyé: 26 mars 2017 8:12 PM À: development at qt-project.org Objet: [Development] P0 Mac help needed due to Daylight savings This test began failing today: FAIL! : tst_QLocale::macDefaultLocale() 'timeString.contains(expectedGMTSpecifier) || timeString.contains(expectedGMTSpecifierZeroExtended)' returned FALSE. (timeString `1:02:03 AM GMT+02:00', expectedGMTSpecifier `GMT+3' or `GMT+03') The expectation is correct, since Finland is now in Summer time at GMT+3. Someone on a Mac, please check why it's getting GMT+02. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Mon Mar 27 08:55:53 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 27 Mar 2017 08:55:53 +0200 Subject: [Development] QList In-Reply-To: References: <710d0e9a324012550a1eb69984a8029c@kdab.com> Message-ID: <201703270855.53949.marc.mutz@kdab.com> On Sunday 26 March 2017 22:53:59 Martin Smith wrote: > >Yes, using vector for an array type was not Stepanov's best choice of > >terms (he says so himself), but what you're doing is like arguing that > >"debt" should be spelled "det". Yes, it should. No, it isn't. :) > > I disagree, but if we have accepted that a vector is a collection, then a > polygon is a vector. Or it at least has a vector. No and no. A vector is a collection of points and so is a polygon. Both are even ordered. But there are good reasons for a polygon to be represented as something else than a vector. E.g. a BSP. Or a platform-specific data type. On some platforms, where everything is a path, it might even make some sense to back QPolygon with QPainterPath. Cf. several paint engine implementations which first have to convert to QPP. (the API is lying here, btw: QPainer::drawPolygon(const QPoint *, int) suggests that you can manage the storage youself to avoid using the heap. But you do that only to have the paint engine create something expensive as a QPainterPath first chance it gets). You just rubberducked me into realizing that QPolygon shouldn't even inherit a QBasicVector. It should probably contain a QPlatformPolygon instead. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From ewleaver at comcast.net Mon Mar 27 09:16:56 2017 From: ewleaver at comcast.net (Ed Leaver) Date: Mon, 27 Mar 2017 01:16:56 -0600 Subject: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug In-Reply-To: <1588347.cVtcoo8qP6@tjmaciei-mobl1> References: <3221217.Il3lxehdtr@tjmaciei-mobl1> <31e6beda-fb72-0a50-d1d4-bc1f8f3ba38e@comcast.net> <1588347.cVtcoo8qP6@tjmaciei-mobl1> Message-ID: <2c6396ab-462f-469d-7717-c4bd8103b78a@comcast.net> Thanks Thiago, Jani, Kevin. Some testing revealed the 5.8.0 and 5.9.0-beta431 sources all compile and install just fine when given the -no-evdev configure switch, which disables evdev gamepads plugin. So I opened the bug against Packaging and Installation instead: QTBUG-59740. Basically, the offline qt-opensource-linux-x64-5.7.1.run installs it's default selections without issue, and starts it's QtCreator 4.2.0 on CentOS 6.8, but subsequent qt-opensource-linux-x64-5.8.0.run, qt-unified-linux-x64-2.0.5-online.run, and qt-unified-linux-x64-2.0.5-1-online.run all fail to install any Qt-5.7.1, Qt-5.8.0, or 5.9.0-beta431 on CentOS 6.8 While I could open an evdev bug, it appears at this point as though that issue has already been addressed. Ed Leaver On 03/23/2017 05:42 PM, Thiago Macieira wrote: > On quinta-feira, 23 de março de 2017 14:54:20 PDT Ed Leaver wrote: >> Hi Thiago, >> >> BTN_TRIGGER_HAPPYxy are a group of kernel #defines, apparently for >> drivers not supported by the 2.6 kernels. Here are my dev notes: >> >> ... Qt-5.8.0 then compiled against gcc-5.4.0 with only one minor >> problem: >> >> qt-everywhere-opensource-src-5.8.0/qtgamepad/src/plugins/gamepads/evdev/qev >> devgamepadbackend.cpp does not compile on CentOS-6.8 (apparently) because >> the >> 2.6.32-642.el6.x86_64 kernel is too old >> and does not define BTN_TRIGGER_HAPPYn (n=1,2,3,4). On Fedora 25 >> these are in >> >> /lib/modules/4.9.14-200.fc25.x86_64/build/include/dt-bindings/input/linux-e >> vent-codes.h I patched qevdevgamepadbackend.cpp with those values: >> #ifndef BTN_TRIGGER_HAPPY1 >> #define BTN_TRIGGER_HAPPY1 0x2c0 >> #define BTN_TRIGGER_HAPPY2 0x2c1 >> #define BTN_TRIGGER_HAPPY3 0x2c2 >> #define BTN_TRIGGER_HAPPY4 0x2c3 >> #endif >> directly above QEvdevGamepadDevice::resetConfiguration(), and then >> the whole Qt-5.8.0 source compiles >> just fine (gcc-5.4.0), although there is a minor issue with final > Please report this issue up to here. The developer will determine whether the > #define is acceptable or not. > From philwave at gmail.com Mon Mar 27 09:22:09 2017 From: philwave at gmail.com (Philippe) Date: Mon, 27 Mar 2017 09:22:09 +0200 Subject: [Development] QList In-Reply-To: <201703270855.53949.marc.mutz@kdab.com> References: <201703270855.53949.marc.mutz@kdab.com> Message-ID: <20170327092208.68D0.6F0322A@gmail.com> > (the API is lying here, btw: QPainer::drawPolygon(const QPoint *, int) > suggests that you can manage the storage youself to avoid using the heap. But > you do that only to have the paint engine create something expensive as a > QPainterPath first chance it gets). No heap allocation if you use the QPointF version with the raster engine. Nor QPainterPath created with the raster engine. Philippe From Martin.Smith at qt.io Mon Mar 27 09:22:53 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 27 Mar 2017 07:22:53 +0000 Subject: [Development] QList In-Reply-To: <201703270855.53949.marc.mutz@kdab.com> References: <710d0e9a324012550a1eb69984a8029c@kdab.com> , <201703270855.53949.marc.mutz@kdab.com> Message-ID: > A vector is a collection of points and so is a polygon. Both are even ordered. vector is an ordered collection of points, but a QVector can contain anything; QVector can even contain unlike things, which is truly a tuple. So the problem here is the name QVector. The basic collection should be called QTuple or QArray, and QVector should mean QTuple. ________________________________ From: Development on behalf of Marc Mutz Sent: Monday, March 27, 2017 8:55:53 AM To: development at qt-project.org Subject: Re: [Development] QList On Sunday 26 March 2017 22:53:59 Martin Smith wrote: > >Yes, using vector for an array type was not Stepanov's best choice of > >terms (he says so himself), but what you're doing is like arguing that > >"debt" should be spelled "det". Yes, it should. No, it isn't. :) > > I disagree, but if we have accepted that a vector is a collection, then a > polygon is a vector. Or it at least has a vector. No and no. A vector is a collection of points and so is a polygon. Both are even ordered. But there are good reasons for a polygon to be represented as something else than a vector. E.g. a BSP. Or a platform-specific data type. On some platforms, where everything is a path, it might even make some sense to back QPolygon with QPainterPath. Cf. several paint engine implementations which first have to convert to QPP. (the API is lying here, btw: QPainer::drawPolygon(const QPoint *, int) suggests that you can manage the storage youself to avoid using the heap. But you do that only to have the paint engine create something expensive as a QPainterPath first chance it gets). You just rubberducked me into realizing that QPolygon shouldn't even inherit a QBasicVector. It should probably contain a QPlatformPolygon instead. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Mon Mar 27 09:35:50 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 27 Mar 2017 09:35:50 +0200 Subject: [Development] QList In-Reply-To: <20170327092208.68D0.6F0322A@gmail.com> References: <201703270855.53949.marc.mutz@kdab.com> <20170327092208.68D0.6F0322A@gmail.com> Message-ID: <201703270935.50911.marc.mutz@kdab.com> On Monday 27 March 2017 09:22:09 Philippe wrote: > > (the API is lying here, btw: QPainer::drawPolygon(const QPoint *, int) > > suggests that you can manage the storage youself to avoid using the heap. > > But you do that only to have the paint engine create something expensive > > as a QPainterPath first chance it gets). > > No heap allocation if you use the QPointF version with the raster engine. > Nor QPainterPath created with the raster engine. Good. But only one paint engine is enough to make a cross-platform API lie. Grepping a bit, QAlphaPaintEngine::drawPolygon() is particularly inefficient. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From andre at familiesomers.nl Mon Mar 27 09:31:13 2017 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Mon, 27 Mar 2017 09:31:13 +0200 Subject: [Development] QList In-Reply-To: References: <710d0e9a324012550a1eb69984a8029c@kdab.com> <201703270855.53949.marc.mutz@kdab.com> Message-ID: Op 27/03/2017 om 09:22 schreef Martin Smith: > > > A vector is a collection of points and so is a polygon. Both > are even ordered. > > > vector is an ordered collection of points, but a QVector can > contain anything; QVector can even contain unlike things, which > is truly a tuple. So the problem here is the name QVector. The basic > collection should be called QTuple or QArray, and QVector should mean > QTuple. > Well, actually, QVector cannot contain unlike things. It can contain only untyped pointers. Of course these can point to whatever you want - unlike to what other pointers in the same QVector are pointing to or not - but the pointers are still of the same type. Note that the objects pointed to are also not contained in the QVector. They are located somewhere else, not managed by the vector. So no, nothing like a tuple at all. André -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eike.Ziller at qt.io Mon Mar 27 09:36:15 2017 From: Eike.Ziller at qt.io (Eike Ziller) Date: Mon, 27 Mar 2017 07:36:15 +0000 Subject: [Development] RFC: Containers member functions for algorithm In-Reply-To: <20170324213359.GA31525@klara.mpi.htwm.de> References: <18416166.MC6PJ1Ml06@maurice> <20170324213359.GA31525@klara.mpi.htwm.de> Message-ID: <5F58850B-BFA8-41C7-A640-B8DB84FC9FC1@qt.io> > On Mar 24, 2017, at 10:33 PM, André Pönitz wrote: > > On Fri, Mar 24, 2017 at 04:25:34PM +0000, Corentin wrote: >> Is std::algo(std::begin(container), std::end(container) ... ) troublesome >> enough that it warrants a wrapper ? > > Yes. > > 1. It is more to read, and more to verify during reading, e.g. > that bother 'container' are the same. > > This typically implies that 'container' is just a simple > identifier for a local variable (i.e. usuall an extra line for > a definition) or a member of the current object (rare). > > Even seeing > > std::algo(std::begin(foo), std::end(foo) ... ) > > *verbatim* with a plain 'foo' does not guarantee that both > 'foo' refer to the same container, i.e. potentially needs > verification when bug hunting. > > For > > std::algo(std::begin(foo()), std::end(foo()) ... ) > > chances are high that it is wrong. Except when it isn't. > But for that you need to consult the declaration, and > even possibly the implementation of 'foo'. > > > 2. It more to type. > > std::algo(std::begin(container), std::end(container) ... ) > > vs > > foo::algo(container, ... ) > > Depending on your project's coding style there are additional > complications, e.g. that the ~55 chars of the first are 'a lot' > in a 80 char-per-line setup. And begin and end are not the only things that can be gotten rid of. The back_inserters you need for things like transform and copy_if are noise for the simple/common case, and I’ve seen a few patches already that forgot the erase after remove_if. > >> Your last example is simplified by the Library Fundamentals TS >> https://rawgit.com/cplusplus/fundamentals-ts/v2/fundamentals-ts.html#container.erasure >> erase_if(std::begin(myList), std::end(myList), [&](const auto &elem) { >> elem.field > someValue; }); > > 100 chars, vs 70 chars for a no-begin-end-cluttered > > erase_if(myList, [&](const auto &elem) { elem.field > someValue; }); > > and some hope that it going from 'myList' to 'myList()' is really > just two chars change. > > Not Nice (TM). > > Andre' > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From marc.mutz at kdab.com Mon Mar 27 09:43:56 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 27 Mar 2017 09:43:56 +0200 Subject: [Development] QList In-Reply-To: References: <201703270855.53949.marc.mutz@kdab.com> Message-ID: <201703270943.57221.marc.mutz@kdab.com> On Monday 27 March 2017 09:22:53 Martin Smith wrote: > vector is an ordered collection of points, but a QVector can contain > anything; QVector can even contain unlike things, which is truly a > tuple. So the problem here is the name QVector. The basic collection > should be called QTuple or QArray, and QVector should mean QTuple. And "debt" should be spelled "det". It should. It isn't. You can start writing det everywhere now, and maybe in a generation you will have collected enough mindshare that the Oxford Dictionary contains it as an alternative spelling. Your grandchildren will thank you for a simplified language, but your children will fight with the fact that debt is now called det. Been there, done that. Delphin is now spelled Delfin in German. For - what - 20 years now? It still looks wrong. Oh, and the public outcry back then. And the economic damage caused by having to re-proofread, re-edit and re-print a ton of Flipper books... https://en.wikipedia.org/wiki/German_orthography_reform_of_1996 Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From giuseppe.dangelo at kdab.com Mon Mar 27 09:45:07 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 27 Mar 2017 09:45:07 +0200 Subject: [Development] QList In-Reply-To: References: <710d0e9a324012550a1eb69984a8029c@kdab.com> <201703270855.53949.marc.mutz@kdab.com> Message-ID: Il 27/03/2017 09:22, Martin Smith ha scritto: > vector is an ordered collection of points, but a QVector can > contain anything; QVector can even contain unlike things, which > is truly a tuple. So the problem here is the name QVector. The basic > collection should be called QTuple or QArray, and QVector should mean > QTuple. > As Marc already told you, the problem here is that there's already 20+ years of experience in the C++ community with the name "vector" indicating a very precise thing (which has nothing to do with geometry or linear spaces). And now there are 6+ years of experience with the names "tuple" and "array" indicating other things (hint: not dynamic data structures). ... what's the point of this discussion, anyhow? -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From lars.knoll at qt.io Mon Mar 27 09:59:58 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 27 Mar 2017 07:59:58 +0000 Subject: [Development] QList In-Reply-To: <201703241718.05520.marc.mutz@kdab.com> References: <201703240934.18483.marc.mutz@kdab.com> <2470039.AWbPmsyYGb@tjmaciei-mobl1> <201703241718.05520.marc.mutz@kdab.com> Message-ID: <82F4CE78-0C24-43F1-9318-35776C71601B@qt.io> On 24 Mar 2017, at 17:18, Marc Mutz > wrote: On Friday 24 March 2017 16:34:17 Thiago Macieira wrote: Em sexta-feira, 24 de março de 2017, às 01:34:18 PDT, Marc Mutz escreveu: I listed _the_ three use-cases where inheritance is the tool of choice: 1. modelling is-a 2. inheriting to reuse 3. reimplementing virtual functions If your use-case is not one of the three, then inheritance is not the right tool. Clearly, by now, it's neither (1) nor (3). So if anything, it needs to be (2). And I'm arguing that it's not (2), either, because you can only re-use a subset of QStringView API, and need to wrap the other half anyway. (2) is really only interesting for pure OO languages with no concept of free functions. In C++, we have free functions. Marc, philosophical question then: Are you of the opinion that private inheritance has no purpose and should never be used? No, and if you look at code I have written over the years, you will see that I do use it. One thing I've looked into in the past is this: Q6Polygon should inherit a Q6VectorBase that also Q6Vector inherits. This will allow easy specialisation of QVector by inheriting QBasicVector. I can even think of a similar pattern for QStringView/QLatin1(String| View)/QUtf8(String|View), though I guess that just enable_if'ing functions out of the primate template will do the job just fine, so the three classes would be mere typedefs of the template. But in these cases, we're reusing next to 100% of the functionality, by way of lots of using Base::foo; This is not the case for QString : QStringView. They're completely unrelated, because one if owning and the other is non- owning. I am with Marc here. I don’t really see any advantage of inheriting QString from QStringView. Rather I think it’ll confuse people, even if the inheritance is private. The pattern I currently think would be best is the following: Make QString and QStringView two independent classes. Share most of the implementation, by either making the const methods in QString call the methods in QStringView (as in QString::indexOf(…) { return QStringView(*this).indexOf(…); }) or by having both call independent methods. The second option might lead to slightly more efficient code, but for operations such as indexOf() I do not think this would matter in practice. On the other hand, the second option might lead to more confusing stack traces if people are debugging their code. In any case, if we decide to go for the second option, I would however like us to move most of these freestanding methods into a (hidden) namespace. Another point that hasn’t been discussed yet, is how to handle QStringRef. In my opinion, we should deprecate it, but it’s used quite a bit in some parts of our API (QXmlStreamReader comes to my mind). It would be good to also think about how to solve that case. QStringRef has a pointer to a QString, but does not increase the refcount of it. So it looks like we can simply make it an alias for QStringView. That would break the QStringRef::string() method (which we should probably deprecate in 5.10 to prepare for the change), but everything else should stay compatible. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Smith at qt.io Mon Mar 27 10:52:36 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 27 Mar 2017 08:52:36 +0000 Subject: [Development] QList In-Reply-To: References: <710d0e9a324012550a1eb69984a8029c@kdab.com> <201703270855.53949.marc.mutz@kdab.com> , Message-ID: >what's the point of this discussion, anyhow? It was about whether QPolygon should inherit QVector, which means that a polygon is a vector. That is kind of jolting because people don't think of a polygon as being a vector. But back in the day, calling a sequential collection of items a vector was also a jolt, because at that time, a vector was a direction and a length to most people. So given the 20 year history of vector being a sequential collection of items, it isn't really a problem for QPolygon to inherit QVector, because everyone will come to think of a polygon as a vector just as we came to think of a vector as a sequential collection of items. ________________________________ From: Development on behalf of Giuseppe D'Angelo Sent: Monday, March 27, 2017 9:45:07 AM To: development at qt-project.org Subject: Re: [Development] QList Il 27/03/2017 09:22, Martin Smith ha scritto: > vector is an ordered collection of points, but a QVector can > contain anything; QVector can even contain unlike things, which > is truly a tuple. So the problem here is the name QVector. The basic > collection should be called QTuple or QArray, and QVector should mean > QTuple. > As Marc already told you, the problem here is that there's already 20+ years of experience in the C++ community with the name "vector" indicating a very precise thing (which has nothing to do with geometry or linear spaces). And now there are 6+ years of experience with the names "tuple" and "array" indicating other things (hint: not dynamic data structures). ... what's the point of this discussion, anyhow? -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Mon Mar 27 10:57:24 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 27 Mar 2017 08:57:24 +0000 Subject: [Development] P0 Mac help needed due to Daylight savings In-Reply-To: <7d917157-ea87-4159-8cf7-d8fcd1712d48@ghs.com> References: <7d917157-ea87-4159-8cf7-d8fcd1712d48@ghs.com> Message-ID: Thiago Macieira (26 mars 2017 8:12 PM) >> This test began failing today: >> FAIL! : tst_QLocale::macDefaultLocale() 'timeString.contains(expectedGMTSpecifier) || timeString.contains(expectedGMTSpecifierZeroExtended)' returned FALSE. >> (timeString `1:02:03 AM GMT+02:00', expectedGMTSpecifier `GMT+3' or `GMT+03') >> The expectation is correct, since Finland is now in Summer time at GMT+3. >> Someone on a Mac, please check why it's getting GMT+02. Rolland Dudemaine (27 March 2017 07:03) > Daylight savings are not done at midnight, but at 2am. See https://en.m.wikipedia.org/wiki/Daylight_saving_time Well, 3am in fact. Hover [0]'s "DST started" box. [0] https://www.timeanddate.com/worldclock/finland/helsinki Not that it makes a difference here. > Seems like Mac is correct, and the test should not fail. Indeed, at 1:2:3 that morning, DST had not yet started. Why did the test expect +3 ? ... /me takes a look ... It uses current time and works out the DST offset at it. Then it builds locale.toString(QTime(1, 2, 3), QLocale::LongFormat) and expects that to have the same offset. This is the bug, in the test. I infer that it passes now and fails two Sundays (less a few hours) per year. If we changed it to use QTime(10, 9, 8) it would only fail for a few hours on each of those two Sundays. Or we could use QDateTime(today, QTime(1, 2, 3)) instead of current time to compute the offset. That would avoid any fails. Might I just take this moment to suggest someone review my many (many) changes to date-time and time-zone code, some of which have languished for more than a year ? I hadn't caught this one, but some of them fix this kind of "that one day (or two) each year it's a problem" bug. ... and those are bugs in the code, not the test, Eddy. From marc.mutz at kdab.com Mon Mar 27 11:27:27 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 27 Mar 2017 11:27:27 +0200 Subject: [Development] P0 Mac help needed due to Daylight savings In-Reply-To: References: <7d917157-ea87-4159-8cf7-d8fcd1712d48@ghs.com> Message-ID: <201703271127.27696.marc.mutz@kdab.com> On Monday 27 March 2017 10:57:24 Edward Welbourne wrote: > Might I just take this moment to suggest someone review my many (many) > changes to date-time and time-zone code, some of which have languished > for more than a year ? I hadn't caught this one, but some of them fix > this kind of "that one day (or two) each year it's a problem" bug. > ... and those are bugs in the code, not the test, If you give a recommended review order for these ... :) -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From julius.bullinger at intel.com Mon Mar 27 11:24:33 2017 From: julius.bullinger at intel.com (Bullinger, Julius) Date: Mon, 27 Mar 2017 09:24:33 +0000 Subject: [Development] first Qt 5.9.0 beta snapshot available In-Reply-To: References: Message-ID: <7FC8D04D3E708B4AA8248F6D64E0CB210D7155F9@IRSMSX104.ger.corp.intel.com> -----Original Message----- From: Development [mailto:development-bounces+julius.bullinger=intel.com at qt-project.org] On Behalf Of Jani Heikkinen Sent: Thursday, March 23, 2017 14:17 To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] first Qt 5.9.0 beta snapshot available > Hi all, > > We have finally first Qt 5.9.0 beta snapshot available via Qt Online Installer for mac and linux users, windows one coming later today or tomorrow > morning. Snapshot is smoke tested & seems to be pretty much OK. > Please download the snaphot (instructions here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer) & take a tour. > Make sure all beta blockers are listed in https://bugreports.qt.io/issues/?filter=18394. > > br, > Jani Hi, I see there are Windows snapshots available for the open source builds since Thursday. Will they also be made available for Enterprise customers? Thanks and best regards, Julius Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 From giuseppe.dangelo at kdab.com Mon Mar 27 11:25:39 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 27 Mar 2017 11:25:39 +0200 Subject: [Development] QList In-Reply-To: References: <710d0e9a324012550a1eb69984a8029c@kdab.com> <201703270855.53949.marc.mutz@kdab.com> Message-ID: <2b79c7ff-8cbd-f80f-9df7-2026690a709d@kdab.com> Il 27/03/2017 10:52, Martin Smith ha scritto: >>what's the point of this discussion, anyhow? > > > It was about whether QPolygon should inherit QVector, which means that a > polygon is a vector. That is kind of jolting because people don't think > of a polygon as being a vector. But back in the day, calling a > sequential collection of items a vector was also a jolt, because at that > time, a vector was a direction and a length to most people. So given the > 20 year history of vector being a sequential collection of items, it > isn't really a problem for QPolygon to inherit QVector, because everyone > will come to think of a polygon as a vector just as we came to think of > a vector as a sequential collection of items. > It *is* a problem, in theory, and in practice, as already expressed countless times. It's also the *fourth* time in a row you're not seeing the paralogism in your reasoning. -- In theory: you're still saying that . points are items . QPolygon is a sequential collection of points . QVector is a sequential collection of items ⊢ QPolygon is-a QVector which is a fallacy. A linked list is also a sequential collection of items, why isn't a QPolygon a QLinkedList? -- In practice: it has been pointed out several times, in this very thread, that there are consequences (due to the various C++/ABI constraints) at exporting subclasses of template classes. Are you even reading those messages instead of insisting on this position? Why are you not replying on the technical details if you believe the reasoning in those messages to be faulty? -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From Shawn.Rutledge at qt.io Mon Mar 27 11:27:59 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 27 Mar 2017 09:27:59 +0000 Subject: [Development] QList In-Reply-To: References: <710d0e9a324012550a1eb69984a8029c@kdab.com> <201703270855.53949.marc.mutz@kdab.com> Message-ID: > On 27 Mar 2017, at 10:52, Martin Smith wrote: > > It was about whether QPolygon should inherit QVector, which means that a polygon is a vector. That is kind of jolting because people don't think of a polygon as being a vector. But back in the day, calling a sequential collection of items a vector was also a jolt, because at that time, a vector was a direction and a length to most people. Well you may think of it that way geometrically, but usually need to do the calculations with vectors in component form. > So given the 20 year history of vector being a sequential collection of items, it isn't really a problem for QPolygon to inherit QVector, because everyone will come to think of a polygon as a vector just as we came to think of a vector as a sequential collection of items. But vector has been overloaded further: it could also be several values aligned in memory in such a way that SIMD (vector-processing) instructions can be used. (And the idea of hardware specialized for vector processing goes way back.) IMO it would have been better to reserve the word for that use in computer science, because it’s more aligned with the mathematical sense of a fixed set of components (one component per dimension), rather than an n-ary array that can be expanded and contracted on demand. If you are processing lots of mathematical vectors, you should probably use vector instructions too. But for some reason it’s not on the radar to worry about SIMD in most code; most of us basically pretend there is no such thing. Is that because compilers are really so good at auto-vectorization that we properly should neglect it, or because the linguistic clutter makes it too confusing, or something else? Should we concern ourselves more about it? Have some features in Qt to make it easier to vectorize code? We have QVector2D, QVector3D and QVector4D, but those are mostly for geometric use cases, whereas float is not the only datatype to which SIMD instructions can be applied. Still, if you have a QVector with 57 elements, you can think of it as a point in 57-dimensional frobspace, if you like. So our use of vector is not completely out of sync with the mathematical sense, even if adding and removing dimensions to our space all the time is kindof absurd. From jani.heikkinen at qt.io Mon Mar 27 11:40:08 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 27 Mar 2017 09:40:08 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: <9505450.rLpQF0vOJZ@tjmaciei-mobl1> , <2265621.Hc078j5Qty@tjmaciei-mobl1> , Message-ID: Hi all, Ok, I have thought this now a while & discussed internally with Tuukka and few others. I have new proposal which is kind of middle between Tuukka's proposal & current process: 1. From FF to beta we will do things as earlier. Of course we need to find ways to cut the time there but it is different story... - Only change is snapshot build distribution via online installer before beta release & beta release as online only (this is already implemented) 2. After first beta release we don't deliver any binary snapshots anymore but do release additional beta releases ~ once per week (with more lightweight process than current releases are done: no blog post from every beta release, limited test round before additional beta N release and full test round when beta N is publicly available, no official approval from release team meetings ...) - This is mandatory step now when delivering snapshot & pre-releases via online installer: New snapshot / pre-releases are updates to previous one -> after beta2 is released there is no first beta available via online installer. 3. When beta N is well enough we will create and release RC. 4. If RC seems to be good enough we will release final but if some blocker found during RC testing we will release immediate RC2 (again with more lightweight process) etc.. br, Jani ________________________________________ From: Development on behalf of Tuukka Turunen Sent: Tuesday, January 03, 2017 10:02 AM To: Simon Hausmann; Thiago Macieira; development at qt-project.org; releasing at qt-project.org Subject: Re: [Development] Proposal to adjust release candidate process Hi, Perhaps it is best to talk with marketing about the name of the “release done immediately after branching to the .0 release branch”. Reading the discussion, it seems that other than the name we are well aligned. Our current process has “Release candidate” 2 weeks prior to the Final release (see: https://wiki.qt.io/Qt5Releasing). If we now have the beta2/preview/othername release 4 weeks before the final, our schedule is the following: Phase Timing Feature freeze T-17 weeks Alpha release T-13 weeks Beta release T-8 weeks Soft string freeze T-6 weeks Hard string freeze T-5 weeks Beta2/Preview/XYZ T-4 weeks Final release T In addition to the main phases, there will be snapshots regularly for testing. During the final weeks before the release these snapshots are then considered as possible final release unless testing reveals a need to change something. This part is unchanged. The main benefit for the change is providing a very close to final package for users to test earlier. During the 4 weeks after Beta there is always a lot of improvements, but after branching to the release branch we should focus only for the high-priority error corrections and polishing the documentation (if not already done earlier). PS. I would like to shorten the overall duration of the release creation to 12 weeks from FF to final. I think that being more strict about the FF and by having all the needed configurations done early enough, we should be able to cut the time between FF and Alpha as well as between Alpha and Beta. But that is something we can discuss later. Yours, Tuukka From: Development [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Simon Hausmann Sent: perjantaina 23. joulukuuta 2016 19.02 To: Thiago Macieira ; development at qt-project.org Subject: Re: [Development] Proposal to adjust release candidate process Ahhh, I'm sorry, I misunderstood your email. Yes, you're right, in that case the branch makes no difference and beta is a better name. Simon ________________________________ From: Development > on behalf of Thiago Macieira > Sent: Friday, December 23, 2016 4:42:12 PM To: development at qt-project.org Subject: Re: [Development] Proposal to adjust release candidate process Em sexta-feira, 23 de dezembro de 2016, às 13:27:30 BRST, Simon Hausmann escreveu: > I find that the branch is relevant in this context, as it relates to the > amount of patches going in. The amount of patches going in is IMO related > to the probably of introducing regressions. The process around the release > branch, as opposed to the "minor branch", as proven to be a useful > mechanism for reducing the churn and making people ask themselves: Do I > really want this change in this release or can it wait? > > So from what I think is one metric of quality (not the only one of course), > the naming of release candidate is more meaningful. How about this, then? We release beta2 from the 5.n branch right before the 5.n.0 branch is created (or finally branches off). It accomplishes the same thing that Tuukka wanted: a release containing the code that is in the 5.n.0 branch at the moment it is created, not a few weeks after with some round of work. And I really mean "the code that is in the 5.n.0 branch". Since the two branches at the same at that point, it's only a semantic difference which one we created the beta2 release from. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Mon Mar 27 11:43:14 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 27 Mar 2017 09:43:14 +0000 Subject: [Development] first Qt 5.9.0 beta snapshot available In-Reply-To: <7FC8D04D3E708B4AA8248F6D64E0CB210D7155F9@IRSMSX104.ger.corp.intel.com> References: <7FC8D04D3E708B4AA8248F6D64E0CB210D7155F9@IRSMSX104.ger.corp.intel.com> Message-ID: > Hi, > > I see there are Windows snapshots available for the open source builds since > Thursday. Will they also be made available for Enterprise customers? > Yes, hoping already today br, Jani > -----Original Message----- > From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- > project.org] On Behalf Of Bullinger, Julius > Sent: maanantaina 27. maaliskuuta 2017 12.25 > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: Re: [Development] first Qt 5.9.0 beta snapshot available > > -----Original Message----- > From: Development [mailto:development- > bounces+julius.bullinger=intel.com at qt-project.org] On Behalf Of Jani > Heikkinen > Sent: Thursday, March 23, 2017 14:17 > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: [Development] first Qt 5.9.0 beta snapshot available > > > Hi all, > > > > We have finally first Qt 5.9.0 beta snapshot available via Qt Online > > Installer for mac and linux users, windows one coming later today or > tomorrow morning. Snapshot is smoke tested & seems to be pretty much OK. > > Please download the snaphot (instructions here: > https://wiki.qt.io/How_to_get_snapshot_via_online_installer) & take a tour. > > Make sure all beta blockers are listed in > https://bugreports.qt.io/issues/?filter=18394. > > > > br, > > Jani > > Hi, > > I see there are Windows snapshots available for the open source builds since > Thursday. Will they also be made available for Enterprise customers? > > Thanks and best regards, > Julius > Intel Deutschland GmbH > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Christian Lamprechter > Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From edward.welbourne at qt.io Mon Mar 27 12:03:37 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 27 Mar 2017 10:03:37 +0000 Subject: [Development] QList In-Reply-To: References: <710d0e9a324012550a1eb69984a8029c@kdab.com> <201703270855.53949.marc.mutz@kdab.com> , Message-ID: On 27 Mar 2017, at 10:52, Martin Smith wrote: >> It was about whether QPolygon should inherit QVector, which means >> that a polygon is a vector. That is kind of jolting because people >> don't think of a polygon as being a vector. But back in the day, >> calling a sequential collection of items a vector was also a jolt, >> because at that time, a vector was a direction and a length to most >> people. Shawn Rutledge (27 March 2017 11:27) > Well you may think of it that way geometrically, but usually need to > do the calculations with vectors in component form. Well, to a linear algebraist (at least this one) a vector is any damn thing you know how to add to similar things and scale by some field of scalings. Which is entirely irrelevant here because we're not talking about linear algebra. The word just means "thing that carries"; indeed, medics use it to talk about things that carry (for example) diseases. Which is still irrelevant because we're not talking about etymology, epidemiology or Latin. In early number-crunching software, there were vector quantities that (entirely naturally) got represented as arrays of numbers; which has lead to a tradition in the world of computer science of using "vector" as a fancy word for an array (with some connotations about how you're treating that array). Which is the relevant meaning of the word because we *are* talking about computer software. >> So given the 20 year history of vector being a sequential collection >> of items, it isn't really a problem for QPolygon to inherit QVector, >> because everyone will come to think of a polygon as a vector just as >> we came to think of a vector as a sequential collection of items. Well, a polygon is a sequential collection of points (officially modulo an equivalence relation that ignores cyclic permutations of the sequence, which just change which vertex you chose to start at; ignoring that equivalence, we have a polygon with one vertex marked, which is a perfectly practical surrogate by which to represent the polygon in software) which does mean it can *be represented* as any old sequential collection of points, but does not in any way select *one particular* choice of implementation as the one that a polygon "is". If the use of a particular implementation of "sequential collection" proves fruitful, by all means use it; but if one proves problematic, perhaps try another. It turns out that (apparently) one of the tool-chains we support behaves badly around exporting a type based on a non-exported template. So let's not do that - oh, woops, we already did, so we have to deal with that as gracefully as we can (and plan on how to unmake this mistake). >> Still, if you have a QVector with 57 elements, you can think of >> it as a point in 57-dimensional frobspace, if you like. So our use >> of vector is not completely out of sync with the mathematical sense, >> even if adding and removing dimensions to our space all the time is >> kindof absurd. Indeed: back to being a linear algebraist, the space of sequential collections of points in one space is itself a linear space, over the same field, albeit of higher dimension; and indeed polygons in the original space can be represented as points in this derived space, albeit the equivalence mentioned above (that it's entirely practical for software to ignore, usually) is going to do some fun things to it, leaving you with a smooth manifold rather than a vector space - but we digress. Eddy. From tuukka.turunen at qt.io Mon Mar 27 12:52:27 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Mon, 27 Mar 2017 10:52:27 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: <9505450.rLpQF0vOJZ@tjmaciei-mobl1> <2265621.Hc078j5Qty@tjmaciei-mobl1> Message-ID: <696A1A0C-CB35-43F2-8B6F-DA634F81511F@qt.io> +1 from me to this improved approach -- Tuukka On 27/03/2017, 12.40, "Development on behalf of Jani Heikkinen" wrote: Hi all, Ok, I have thought this now a while & discussed internally with Tuukka and few others. I have new proposal which is kind of middle between Tuukka's proposal & current process: 1. From FF to beta we will do things as earlier. Of course we need to find ways to cut the time there but it is different story... - Only change is snapshot build distribution via online installer before beta release & beta release as online only (this is already implemented) 2. After first beta release we don't deliver any binary snapshots anymore but do release additional beta releases ~ once per week (with more lightweight process than current releases are done: no blog post from every beta release, limited test round before additional beta N release and full test round when beta N is publicly available, no official approval from release team meetings ...) - This is mandatory step now when delivering snapshot & pre-releases via online installer: New snapshot / pre-releases are updates to previous one -> after beta2 is released there is no first beta available via online installer. 3. When beta N is well enough we will create and release RC. 4. If RC seems to be good enough we will release final but if some blocker found during RC testing we will release immediate RC2 (again with more lightweight process) etc.. br, Jani ________________________________________ From: Development on behalf of Tuukka Turunen Sent: Tuesday, January 03, 2017 10:02 AM To: Simon Hausmann; Thiago Macieira; development at qt-project.org; releasing at qt-project.org Subject: Re: [Development] Proposal to adjust release candidate process Hi, Perhaps it is best to talk with marketing about the name of the “release done immediately after branching to the .0 release branch”. Reading the discussion, it seems that other than the name we are well aligned. Our current process has “Release candidate” 2 weeks prior to the Final release (see: https://wiki.qt.io/Qt5Releasing). If we now have the beta2/preview/othername release 4 weeks before the final, our schedule is the following: Phase Timing Feature freeze T-17 weeks Alpha release T-13 weeks Beta release T-8 weeks Soft string freeze T-6 weeks Hard string freeze T-5 weeks Beta2/Preview/XYZ T-4 weeks Final release T In addition to the main phases, there will be snapshots regularly for testing. During the final weeks before the release these snapshots are then considered as possible final release unless testing reveals a need to change something. This part is unchanged. The main benefit for the change is providing a very close to final package for users to test earlier. During the 4 weeks after Beta there is always a lot of improvements, but after branching to the release branch we should focus only for the high-priority error corrections and polishing the documentation (if not already done earlier). PS. I would like to shorten the overall duration of the release creation to 12 weeks from FF to final. I think that being more strict about the FF and by having all the needed configurations done early enough, we should be able to cut the time between FF and Alpha as well as between Alpha and Beta. But that is something we can discuss later. Yours, Tuukka From: Development [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Simon Hausmann Sent: perjantaina 23. joulukuuta 2016 19.02 To: Thiago Macieira ; development at qt-project.org Subject: Re: [Development] Proposal to adjust release candidate process Ahhh, I'm sorry, I misunderstood your email. Yes, you're right, in that case the branch makes no difference and beta is a better name. Simon ________________________________ From: Development > on behalf of Thiago Macieira > Sent: Friday, December 23, 2016 4:42:12 PM To: development at qt-project.org Subject: Re: [Development] Proposal to adjust release candidate process Em sexta-feira, 23 de dezembro de 2016, às 13:27:30 BRST, Simon Hausmann escreveu: > I find that the branch is relevant in this context, as it relates to the > amount of patches going in. The amount of patches going in is IMO related > to the probably of introducing regressions. The process around the release > branch, as opposed to the "minor branch", as proven to be a useful > mechanism for reducing the churn and making people ask themselves: Do I > really want this change in this release or can it wait? > > So from what I think is one metric of quality (not the only one of course), > the naming of release candidate is more meaningful. How about this, then? We release beta2 from the 5.n branch right before the 5.n.0 branch is created (or finally branches off). It accomplishes the same thing that Tuukka wanted: a release containing the code that is in the 5.n.0 branch at the moment it is created, not a few weeks after with some round of work. And I really mean "the code that is in the 5.n.0 branch". Since the two branches at the same at that point, it's only a semantic difference which one we created the beta2 release from. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Martin.Smith at qt.io Mon Mar 27 12:54:41 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 27 Mar 2017 10:54:41 +0000 Subject: [Development] QList In-Reply-To: <2b79c7ff-8cbd-f80f-9df7-2026690a709d@kdab.com> References: <710d0e9a324012550a1eb69984a8029c@kdab.com> <201703270855.53949.marc.mutz@kdab.com> , <2b79c7ff-8cbd-f80f-9df7-2026690a709d@kdab.com> Message-ID: >It's also the *fourth* time in a row you're not seeing the paralogism in >your reasoning. >In theory: you're still saying that >. points are items >. QPolygon is a sequential collection of points . QVector is a sequential collection of items >⊢ QPolygon is-a QVector >which is a fallacy. >A linked list is also a sequential collection of items, why isn't a >QPolygon a QLinkedList? Because QPolygon actually inherits QVector, and when you create a QPolygon, you must create it with a QVector of QPoint. So a QPolygon IS a QVector. That's not the whole story, of course, because to create a QPolygon, the items you put in the QVector must be QPoints. >Why are you not replying on the technical details if you >believe the reasoning in those messages to be faulty? Because I don't disagree with the reasoning, and I agree that QPolygon should not inherit QVector, but I'm saying that makes sense because a polygon is not a vector. ________________________________ From: giuseppe.dangelo at kdab.com on behalf of Giuseppe D'Angelo Sent: Monday, March 27, 2017 11:25:39 AM To: Martin Smith; development at qt-project.org Subject: Re: [Development] QList Il 27/03/2017 10:52, Martin Smith ha scritto: >>what's the point of this discussion, anyhow? > > > It was about whether QPolygon should inherit QVector, which means that a > polygon is a vector. That is kind of jolting because people don't think > of a polygon as being a vector. But back in the day, calling a > sequential collection of items a vector was also a jolt, because at that > time, a vector was a direction and a length to most people. So given the > 20 year history of vector being a sequential collection of items, it > isn't really a problem for QPolygon to inherit QVector, because everyone > will come to think of a polygon as a vector just as we came to think of > a vector as a sequential collection of items. > It *is* a problem, in theory, and in practice, as already expressed countless times. It's also the *fourth* time in a row you're not seeing the paralogism in your reasoning. -- In theory: you're still saying that . points are items . QPolygon is a sequential collection of points . QVector is a sequential collection of items ⊢ QPolygon is-a QVector which is a fallacy. A linked list is also a sequential collection of items, why isn't a QPolygon a QLinkedList? -- In practice: it has been pointed out several times, in this very thread, that there are consequences (due to the various C++/ABI constraints) at exporting subclasses of template classes. Are you even reading those messages instead of insisting on this position? Why are you not replying on the technical details if you believe the reasoning in those messages to be faulty? -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- An HTML attachment was scrubbed... URL: From philwave at gmail.com Mon Mar 27 13:05:52 2017 From: philwave at gmail.com (Philippe) Date: Mon, 27 Mar 2017 13:05:52 +0200 Subject: [Development] QList In-Reply-To: <2b79c7ff-8cbd-f80f-9df7-2026690a709d@kdab.com> References: <2b79c7ff-8cbd-f80f-9df7-2026690a709d@kdab.com> Message-ID: <20170327130551.2B18.6F0322A@gmail.com> > . points are items > . QPolygon is a sequential collection of points > . QVector is a sequential collection of items > ? QPolygon is-a QVector > > which is a fallacy. QPolygon needs not be a QVector QPolygon can be a QVector QPolygon can be a QList ...but *today*, QPolygon is "implemented as a QVector" Hence from the OO common dialect, QPolygon is-a QVector Philippe From giuseppe.dangelo at kdab.com Mon Mar 27 13:35:20 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 27 Mar 2017 13:35:20 +0200 Subject: [Development] QList In-Reply-To: <20170327130551.2B18.6F0322A@gmail.com> References: <2b79c7ff-8cbd-f80f-9df7-2026690a709d@kdab.com> <20170327130551.2B18.6F0322A@gmail.com> Message-ID: <0eba1dd8-bfb2-f2e2-d028-e90bffab3621@kdab.com> Il 27/03/2017 13:05, Philippe ha scritto: > QPolygon needs not be a QVector > QPolygon can be a QVector > QPolygon can be a QList ... which confirms the fallacy. > > ...but *today*, QPolygon is "implemented as a QVector" > Hence from the OO common dialect, QPolygon is-a QVector This subthread wasn't arguing with that (and you've already got an answer about why "implemented as a QVector" was a bad idea), but with the formal fallacies in the arguments exposed so far (four in four messages, and I'm not even counting the argument from authority when CS/Math were brought to the table without an invitation). Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From Martin.Smith at qt.io Mon Mar 27 13:47:36 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 27 Mar 2017 11:47:36 +0000 Subject: [Development] QList In-Reply-To: <0eba1dd8-bfb2-f2e2-d028-e90bffab3621@kdab.com> References: <2b79c7ff-8cbd-f80f-9df7-2026690a709d@kdab.com> <20170327130551.2B18.6F0322A@gmail.com>, <0eba1dd8-bfb2-f2e2-d028-e90bffab3621@kdab.com> Message-ID: > I'm not even counting the argument from authority when >CS/Math were brought to the table without an invitation I will keep bringing them to the table because, as a documentation guy following this and other similar discussions, it looks like you (plural) are willing to ignore the importance of naming things in the API because of technical problems with implementations in C++. ________________________________ From: Development on behalf of Giuseppe D'Angelo Sent: Monday, March 27, 2017 1:35:20 PM To: development at qt-project.org Subject: Re: [Development] QList Il 27/03/2017 13:05, Philippe ha scritto: > QPolygon needs not be a QVector > QPolygon can be a QVector > QPolygon can be a QList ... which confirms the fallacy. > > ...but *today*, QPolygon is "implemented as a QVector" > Hence from the OO common dialect, QPolygon is-a QVector This subthread wasn't arguing with that (and you've already got an answer about why "implemented as a QVector" was a bad idea), but with the formal fallacies in the arguments exposed so far (four in four messages, and I'm not even counting the argument from authority when CS/Math were brought to the table without an invitation). Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Mar 27 09:29:33 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Mar 2017 00:29:33 -0700 Subject: [Development] QList In-Reply-To: References: <201703270855.53949.marc.mutz@kdab.com> Message-ID: <3519135.gYpynqj7GC@tjmaciei-mobl1> On segunda-feira, 27 de março de 2017 00:22:53 PDT Martin Smith wrote: > QVector should mean QTuple. The name "tuple" has since been repurposed to mean something different. We could go back to Qt 1 name "QArray", but I feel the boat has sailed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Mar 27 17:36:38 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Mar 2017 08:36:38 -0700 Subject: [Development] QList In-Reply-To: <201703270943.57221.marc.mutz@kdab.com> References: <201703270943.57221.marc.mutz@kdab.com> Message-ID: <2856553.oiUPD2vfiy@tjmaciei-mobl1> On segunda-feira, 27 de março de 2017 00:43:56 PDT Marc Mutz wrote: > Been there, done that. Delphin is now spelled Delfin in German. For - what - > 20 years now? It still looks wrong. Oh, and the public outcry back then. > And the economic damage caused by having to re-proofread, re-edit and > re-print a ton of Flipper books... > > https://en.wikipedia.org/wiki/German_orthography_reform_of_1996 Oh, yeah, they almost did that to Superman in Portuguese too ("super-homem") by dropping the hyphen and the 'h'. https://en.wikipedia.org/wiki/ Portuguese_Language_Orthographic_Agreement_of_1990 I still miss the trema/diaeresis ("umlaut" sign)... the next generation won't know if "frequency" and "liquid" is pronounced with a /k/ (like in French) or a /kʷ/ sound (like in English). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Mon Mar 27 17:43:48 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 27 Mar 2017 11:43:48 -0400 Subject: [Development] OT: English phonetic spelling (was: QList) In-Reply-To: <201703270943.57221.marc.mutz@kdab.com> References: <201703270855.53949.marc.mutz@kdab.com> <201703270943.57221.marc.mutz@kdab.com> Message-ID: <58D93334.4040306@gmail.com> On 2017-03-27 03:43, Marc Mutz wrote: > And "debt" should be spelled "det". It should. It isn't. You can start writing > det everywhere now, and maybe in a generation you will have collected enough > mindshare that the Oxford Dictionary contains it as an alternative spelling. > Your grandchildren will thank you for a simplified language, but your children > will fight with the fact that debt is now called det. Yeah, that just looks wrong. If we were to ever do such things, I would much rather switch wholesale to a completely phonetic spelling of everything :-). Just for fun... Iä, thät güst lûks wråŋ. Yf wi wÿr tu ëvÿr du süch thyŋz, ai wûd müch räthÿr swytch holsel tu ü kümplitli fünëtyk spëlyŋ üf ëvrithyŋ. Ai häpyn tu lüik thys systûm wych ai ëm dëmünstretyŋ hir ;-). (Yeah... I've given this "some" thought before now :-)... writing takes practice, but *reading* is surprisingly easy... at least if you can pronounce latin-derived langauges. There are 12 distinct vowel characters and 22 distinct consonant characters, but - with one exception - each has a single, distinct pronunciation. The exception is 'h', which may appear by itself, or as the second character of 5 two-character consonants.) > Been there, done that. Delphin is now spelled Delfin in German. For - what - > 20 years now? It still looks wrong. Oh, and the public outcry back then. And > the economic damage caused by having to re-proofread, re-edit and re-print a > ton of Flipper books... ...and, correct me if I'm wrong, but German is generally spelled how it is pronounced, yes? -- Matthew From thiago.macieira at intel.com Mon Mar 27 17:46:41 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Mar 2017 08:46:41 -0700 Subject: [Development] QList In-Reply-To: <82F4CE78-0C24-43F1-9318-35776C71601B@qt.io> References: <201703241718.05520.marc.mutz@kdab.com> <82F4CE78-0C24-43F1-9318-35776C71601B@qt.io> Message-ID: <2867454.cgdXHHexsp@tjmaciei-mobl1> On segunda-feira, 27 de março de 2017 00:59:58 PDT Lars Knoll wrote: > I am with Marc here. I don’t really see any advantage of inheriting QString > from QStringView. Rather I think it’ll confuse people, even if the > inheritance is private. I guess I will just have to prove that: a) code generation will be better b) maintenance will be lower c) people will not be confused (because they won't know) > The pattern I currently think would be best is the following: > > Make QString and QStringView two independent classes. Share most of the > implementation, by either making the const methods in QString call the > methods in QStringView (as in QString::indexOf(…) { return > QStringView(*this).indexOf(…); }) or by having both call independent > methods. The second option might lead to slightly more efficient code, but > for operations such as indexOf() I do not think this would matter in > practice. On the other hand, the second option might lead to more confusing > stack traces if people are debugging their code. In any case, if we decide > to go for the second option, I would however like us to move most of these > freestanding methods into a (hidden) namespace. That's probably partially solving (a) and making the best code generation for user code, at the expense of either increasing code size in QtCore by having more entry points or by inlining everything in qstring.h. Either way, it's not solving (b): maintenance will be higher by increasing duplication of code. Just look at how much of QString's API is *not* in QStringRef aven after 10 years that it has existed. > Another point that hasn’t been discussed yet, is how to handle QStringRef. > In my opinion, we should deprecate it, but it’s used quite a bit in some > parts of our API (QXmlStreamReader comes to my mind). It would be good to > also think about how to solve that case. QStringRef has a pointer to a > QString, but does not increase the refcount of it. So it looks like we can > simply make it an alias for QStringView. That would break the > QStringRef::string() method (which we should probably deprecate in 5.10 to > prepare for the change), but everything else should stay compatible. We can't... I tried that a while ago and it broke QXmlStreamReader and other places badly. The issue is that they expect QStringRef to continue to be valid after mutating the QString it was bound to. That works because of the pointer to the QString, as opposed to a pointer to the data. And that's just what I found by after changing QStringRef a few years ago to be like QStringView today and simply running Qt Creator. We can port away from QStringRef and into QStringView as we go by and where it's safe. But unless we're willing to refactor some code substantially. Unfortunately, it's very likely we can't begin this work now as it would break the QStringRef API and thus be BIC/SIC. So, yes, deprecate, but we'll have to carry QStringRef for some time, like QRegExp. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Mar 27 17:50:20 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Mar 2017 08:50:20 -0700 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: Message-ID: <10813507.0tU7pd7eKk@tjmaciei-mobl1> On segunda-feira, 27 de março de 2017 02:40:08 PDT Jani Heikkinen wrote: > 2. After first beta release we don't deliver any binary snapshots anymore > but do release additional beta releases ~ once per week (with more > lightweight process than current releases are done: no blog post from every > beta release, limited test round before additional beta N release and full > test round when beta N is publicly available, no official approval from > release team meetings ...) - This is mandatory step now when delivering > snapshot & pre-releases via online installer: New snapshot / pre-releases > are updates to previous one -> after beta2 is released there is no first > beta available via online installer. 3. When beta N is well enough we will > create and release RC. > 4. If RC seems to be good enough we will release final but if some blocker > found during RC testing we will release immediate RC2 (again with more > lightweight process) etc.. Sounds good, but please remember we'll need to keep at least the source tarballs for each and every beta and RC that we release. Maybe every week is too aggressive, since few people will test every week and give feedback in time for the next release. We may find that every other week is better. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From konrad at silmor.de Mon Mar 27 18:44:16 2017 From: konrad at silmor.de (Konrad Rosenbaum) Date: Mon, 27 Mar 2017 18:44:16 +0200 Subject: [Development] OT: English phonetic spelling (was: QList) In-Reply-To: <58D93334.4040306@gmail.com> References: <201703270855.53949.marc.mutz@kdab.com> <201703270943.57221.marc.mutz@kdab.com> <58D93334.4040306@gmail.com> Message-ID: <9b9bf0af2fd66697bf9eaeebd112d7c3.squirrel@squirrel.six.silmor.de> [quite OT, but I'll pile on... - just for fun] On Mon, March 27, 2017 17:43, Matthew Woehlke wrote: > Iä, thät güst lûks wråŋ. Yf wi wÿr tu ëvÿr du süch thyŋz, ai wûd müch Let me propose the more "Jusfull" "Jäh" - which is somewhat easier to read. > räthÿr swytch holsel tu ü kümplitli fünëtyk spëlyŋ üf ëvrithyŋ. Ai häpyn > tu lüik thys systûm wych ai ëm dëmünstretyŋ hir ;-). Are you using Gaelic pronunciation on "lüik"? The only way my tongue seems able to pronounce this is with an almost silent "i". > On 2017-03-27 03:43, Marc Mutz wrote: >> Been there, done that. Delphin is now spelled Delfin in German. For - >> what - >> 20 years now? It still looks wrong. Oh, and the public outcry back then. >> And >> the economic damage caused by having to re-proofread, re-edit and >> re-print a >> ton of Flipper books... > > ...and, correct me if I'm wrong, but German is generally spelled how it > is pronounced, yes? Yes, German is almost completely phonetic - except for very few loan words that have not completely assimilated yet. But there are efforts under way to send them on an integration and language course, now that they've gained asylum and are proven to be mostly harmless. The perceived "problem" they tried to solve with the reform was that several phonemes have more than one possible spelling (e.g. "f" and "ph" as demonstrated above) and there were some minor exceptions to grammatical rules (e.g. conversion between "ss" and "ß" is not entirely logical all the time). ...while all of this supposedly made things easier for young students, it's hell for scientifically minded adults - it's called "Telefon" now, but the "f" in there is still a quite foreign "Phonem" (both derived from the greek word for sound), while the aficionado of ancient greek in the other room insists that "this is not how you spell greek words! It's the wrong alphabet(*)." :-( (*) or is this Alfabet now - I can never remember this one In short: even completely phonetic languages with reforms that make the language even more logical and phonetic provide ample opportunity to screw up the spelling of several generations while also providing for futile, but heated, discussions and some bloody noses. Please keep English weird! That makes it likeable. Konrad From jtranter at ics.com Mon Mar 27 19:09:41 2017 From: jtranter at ics.com (Jeff Tranter) Date: Mon, 27 Mar 2017 13:09:41 -0400 Subject: [Development] OT: English phonetic spelling In-Reply-To: <9b9bf0af2fd66697bf9eaeebd112d7c3.squirrel@squirrel.six.silmor.de> References: <201703270855.53949.marc.mutz@kdab.com> <201703270943.57221.marc.mutz@kdab.com> <58D93334.4040306@gmail.com> <9b9bf0af2fd66697bf9eaeebd112d7c3.squirrel@squirrel.six.silmor.de> Message-ID: On 17-03-27 12:44 PM, Konrad Rosenbaum wrote: > [quite OT, but I'll pile on... - just for fun] > > On Mon, March 27, 2017 17:43, Matthew Woehlke wrote: >> Iä, thät güst lûks wråŋ. Yf wi wÿr tu ëvÿr du süch thyŋz, ai > wûd müch > > Let me propose the more "Jusfull" "Jäh" - which is somewhat easier to read. > >> räthÿr swytch holsel tu ü kümplitli fünëtyk spëlyŋ üf > ëvrithyŋ. Ai häpyn >> tu lüik thys systûm wych ai ëm dëmünstretyŋ hir ;-). > > Are you using Gaelic pronunciation on "lüik"? The only way my tongue seems > able to pronounce this is with an almost silent "i". > >> On 2017-03-27 03:43, Marc Mutz wrote: >>> Been there, done that. Delphin is now spelled Delfin in German. For - >>> what - >>> 20 years now? It still looks wrong. Oh, and the public outcry back then. >>> And >>> the economic damage caused by having to re-proofread, re-edit and >>> re-print a >>> ton of Flipper books... >> >> ...and, correct me if I'm wrong, but German is generally spelled how it >> is pronounced, yes? > > Yes, German is almost completely phonetic - except for very few loan words > that have not completely assimilated yet. But there are efforts under way > to send them on an integration and language course, now that they've > gained asylum and are proven to be mostly harmless. > > The perceived "problem" they tried to solve with the reform was that > several phonemes have more than one possible spelling (e.g. "f" and "ph" > as demonstrated above) and there were some minor exceptions to grammatical > rules (e.g. conversion between "ss" and "ß" is not entirely logical all > the time). > > ...while all of this supposedly made things easier for young students, > it's hell for scientifically minded adults - it's called "Telefon" now, > but the "f" in there is still a quite foreign "Phonem" (both derived from > the greek word for sound), while the aficionado of ancient greek in the > other room insists that "this is not how you spell greek words! It's the > wrong alphabet(*)." :-( > > (*) or is this Alfabet now - I can never remember this one > > In short: even completely phonetic languages with reforms that make the > language even more logical and phonetic provide ample opportunity to screw > up the spelling of several generations while also providing for futile, > but heated, discussions and some bloody noses. > > Please keep English weird! That makes it likeable. This brings to mind "A Plan for the Improvement of English Spelling" by Mark Twain. You can Google it. > > Konrad > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Jeff Tranter, Engineering Manager, Integrated Computer Solutions. ICS - Qt Software Development Services and Training http://ics.com/services/ From mwoehlke.floss at gmail.com Mon Mar 27 19:33:36 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 27 Mar 2017 13:33:36 -0400 Subject: [Development] OT: English phonetic spelling In-Reply-To: <9b9bf0af2fd66697bf9eaeebd112d7c3.squirrel@squirrel.six.silmor.de> References: <201703270855.53949.marc.mutz@kdab.com> <201703270943.57221.marc.mutz@kdab.com> <58D93334.4040306@gmail.com> <9b9bf0af2fd66697bf9eaeebd112d7c3.squirrel@squirrel.six.silmor.de> Message-ID: <58D94CF0.4050509@gmail.com> On 2017-03-27 12:44, Konrad Rosenbaum wrote: > [quite OT, but I'll pile on... - just for fun] > > On Mon, March 27, 2017 17:43, Matthew Woehlke wrote: >> Iä, thät güst lûks wråŋ. Yf wi wÿr tu ëvÿr du süch thyŋz, ai >> wûd müch > > Let me propose the more "Jusfull" "Jäh" - which is somewhat easier to read. Huh. That's a good point... although there are no silent letters, so it would be "jä", not "jäh". (Also: "jusfûl"; "ful" → fool, "fûl" → full. In fairness I didn't use 'û' in the original example :-).) >> räthÿr swytch holsel tu ü kümplitli fünëtyk spëlyŋ üf >> ëvrithyŋ. Ai häpyn >> tu lüik thys systûm wych ai ëm dëmünstretyŋ hir ;-). > > Are you using Gaelic pronunciation on "lüik"? The only way my tongue seems > able to pronounce this is with an almost silent "i". Since I don't know what the "Gaelic pronunciation on 'lüik'" *is*, I can't answer that :-). Note also "ü" as an article; it is pronounced as in "thumb" ("up", "what", etc.). The "üi" (as in "bike") is a rather strange dipthong. >> ...and, correct me if I'm wrong, but German is generally spelled how it >> is pronounced, yes? > > Yes, German is almost completely phonetic - except for very few loan words > that have not completely assimilated yet. But there are efforts under way > to send them on an integration and language course, now that they've > gained asylum and are proven to be mostly harmless. :-D > In short: even completely phonetic languages with reforms that make the > language even more logical and phonetic provide ample opportunity to screw > up the spelling of several generations while also providing for futile, > but heated, discussions and some bloody noses. Heh. Aaaaaaand... we won't talk about accents :-). Strictly speaking, a rigidly phonetic spelling would differ in spelling, perhaps dramatically, depending on region. (On the other hand, it makes http://tvtropes.org/pmwiki/pmwiki.php/Main/FunetikAksent really easy and accessible.) -- Matthew From giuseppe.dangelo at kdab.com Mon Mar 27 20:14:24 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 27 Mar 2017 20:14:24 +0200 Subject: [Development] QList In-Reply-To: <2867454.cgdXHHexsp@tjmaciei-mobl1> References: <201703241718.05520.marc.mutz@kdab.com> <82F4CE78-0C24-43F1-9318-35776C71601B@qt.io> <2867454.cgdXHHexsp@tjmaciei-mobl1> Message-ID: Il 27/03/2017 17:46, Thiago Macieira ha scritto: >> Another point that hasn’t been discussed yet, is how to handle QStringRef. >> In my opinion, we should deprecate it, but it’s used quite a bit in some >> parts of our API (QXmlStreamReader comes to my mind). It would be good to >> also think about how to solve that case. QStringRef has a pointer to a >> QString, but does not increase the refcount of it. So it looks like we can >> simply make it an alias for QStringView. That would break the >> QStringRef::string() method (which we should probably deprecate in 5.10 to >> prepare for the change), but everything else should stay compatible. > We can't... I tried that a while ago and it broke QXmlStreamReader and other > places badly. The issue is that they expect QStringRef to continue to be valid > after mutating the QString it was bound to. That works because of the pointer > to the QString, as opposed to a pointer to the data. And that's just what I > found by after changing QStringRef a few years ago to be like QStringView > today and simply running Qt Creator. > > We can port away from QStringRef and into QStringView as we go by and where > it's safe. But unless we're willing to refactor some code substantially. > Unfortunately, it's very likely we can't begin this work now as it would break > the QStringRef API and thus be BIC/SIC. If we can't make it an alias, can we start adding extra functions for the various QStringRef *ref() methods (in QXmlStreamReader, QRegularExpressionMatch, probably elsewhere too), returning QStringView? Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From apoenitz at t-online.de Mon Mar 27 21:03:55 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 27 Mar 2017 21:03:55 +0200 Subject: [Development] QList In-Reply-To: References: <710d0e9a324012550a1eb69984a8029c@kdab.com> <201703270855.53949.marc.mutz@kdab.com> Message-ID: <20170327190355.GA2948@klara.mpi.htwm.de> On Mon, Mar 27, 2017 at 09:45:07AM +0200, Giuseppe D'Angelo wrote: > Il 27/03/2017 09:22, Martin Smith ha scritto: > > vector is an ordered collection of points, but a QVector can > > contain anything; QVector can even contain unlike things, which > > is truly a tuple. So the problem here is the name QVector. The basic > > collection should be called QTuple or QArray, and QVector should mean > > QTuple. > > As Marc already told you, the problem here is that there's already 20+ > years of experience in the C++ community with the name "vector" > indicating a very precise thing (which has nothing to do with geometry > or linear spaces). Since when is $SOME_COMMUNITY_WE_ARE_INTERESTED_IN is using $FEATURE since $ETERNITY a valid argument in this thread here? Andre' From giuseppe.dangelo at kdab.com Mon Mar 27 21:09:24 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 27 Mar 2017 21:09:24 +0200 Subject: [Development] QList In-Reply-To: <20170327190355.GA2948@klara.mpi.htwm.de> References: <710d0e9a324012550a1eb69984a8029c@kdab.com> <201703270855.53949.marc.mutz@kdab.com> <20170327190355.GA2948@klara.mpi.htwm.de> Message-ID: <88b6ebc5-1de0-36a3-db26-5c5dcb18acbb@kdab.com> Il 27/03/2017 21:03, André Pönitz ha scritto: >>> vector is an ordered collection of points, but a QVector can >>> contain anything; QVector can even contain unlike things, which >>> is truly a tuple. So the problem here is the name QVector. The basic >>> collection should be called QTuple or QArray, and QVector should mean >>> QTuple. >> As Marc already told you, the problem here is that there's already 20+ >> years of experience in the C++ community with the name "vector" >> indicating a very precise thing (which has nothing to do with geometry >> or linear spaces). > Since when is $SOME_COMMUNITY_WE_ARE_INTERESTED_IN is using $FEATURE > since $ETERNITY a valid argument in this thread here? When people started doing claims about "how things should be named (and why)" (which, yes, itself was an unnecessary thread derailment. But I didn't start *that*.) Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From scott at towel42.com Mon Mar 27 21:19:38 2017 From: scott at towel42.com (Scott Aron Bloom) Date: Mon, 27 Mar 2017 19:19:38 +0000 Subject: [Development] QList In-Reply-To: <88b6ebc5-1de0-36a3-db26-5c5dcb18acbb@kdab.com> References: <710d0e9a324012550a1eb69984a8029c@kdab.com> <201703270855.53949.marc.mutz@kdab.com> <20170327190355.GA2948@klara.mpi.htwm.de> <88b6ebc5-1de0-36a3-db26-5c5dcb18acbb@kdab.com> Message-ID: -----Original Message----- From: Development [mailto:development-bounces+scott=towel42.com at qt-project.org] On Behalf Of Giuseppe D'Angelo Sent: Monday, March 27, 2017 12:09 To: André Pönitz Cc: development at qt-project.org Subject: Re: [Development] QList Il 27/03/2017 21:03, André Pönitz ha scritto: >>> vector is an ordered collection of points, but a QVector can >>> contain anything; QVector can even contain unlike things, >>> which is truly a tuple. So the problem here is the name QVector. The >>> basic collection should be called QTuple or QArray, and QVector >>> should mean QTuple. >> As Marc already told you, the problem here is that there's already >> 20+ years of experience in the C++ community with the name "vector" >> indicating a very precise thing (which has nothing to do with >> geometry or linear spaces). > Since when is $SOME_COMMUNITY_WE_ARE_INTERESTED_IN is using $FEATURE > since $ETERNITY a valid argument in this thread here? When people started doing claims about "how things should be named (and why)" (which, yes, itself was an unnecessary thread derailment. But I didn't start *that*.) Cheers, ========= My two bits, as a 15+ year Qt professional level user, and semi-active qt-list person, who is on this list to see whats going on, but doesn’t have much time to actively develop... Sometimes called a whiner 😊 Calling it a "List" is wrong...it does imply linked list... If you wanted to have two "vectors" of different levels of optimization, QArray and QVector would have been my preference. As somone who lived through the Qt 3->4 pain, (and who as a consultant helped 30+ projects do the conversion), it was painful. But not because of the naming, mostly because of lost functionality that didn’t exist until Graphics View came back To be honest, I forget which "view" Qt3 used that had to wait until Qt4's QGraphicsView was of full quality. Also, the major change was converting all of our "non MVC" based systems to the QModelIndex/Model world.. But once you learned how to think in the new world, it wasn’t too bad.. The issue became a matter of "re-write" not Qt3-4 ports. If it were up to me.. I would love to see Qt focus on containers that Qt MUST have that add SIGNIFICANT value to the Qt world, NOT "well when we started, there was no stl" version. For instance, I do see the value of QString for translation in the Qt world. Others may disagree, but QList std::list or std::vector, or QSet, makes NO sense to me for Qt to keep. Scott From apoenitz at t-online.de Mon Mar 27 21:25:00 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 27 Mar 2017 21:25:00 +0200 Subject: [Development] QList In-Reply-To: <88b6ebc5-1de0-36a3-db26-5c5dcb18acbb@kdab.com> References: <710d0e9a324012550a1eb69984a8029c@kdab.com> <201703270855.53949.marc.mutz@kdab.com> <20170327190355.GA2948@klara.mpi.htwm.de> <88b6ebc5-1de0-36a3-db26-5c5dcb18acbb@kdab.com> Message-ID: <20170327192500.GA3047@klara.mpi.htwm.de> On Mon, Mar 27, 2017 at 09:09:24PM +0200, Giuseppe D'Angelo wrote: > Il 27/03/2017 21:03, André Pönitz ha scritto: > >>> vector is an ordered collection of points, but a QVector can > >>> contain anything; QVector can even contain unlike things, which > >>> is truly a tuple. So the problem here is the name QVector. The basic > >>> collection should be called QTuple or QArray, and QVector should mean > >>> QTuple. > >> As Marc already told you, the problem here is that there's already 20+ > >> years of experience in the C++ community with the name "vector" > >> indicating a very precise thing (which has nothing to do with geometry > >> or linear spaces). > > Since when is $SOME_COMMUNITY_WE_ARE_INTERESTED_IN is using $FEATURE > > since $ETERNITY a valid argument in this thread here? > > When people started doing claims about "how things should be named (and > why)" (which, yes, itself was an unnecessary thread derailment. But I > didn't start *that*.) So that was after the argument of QList being used for a decade by Qt users was dismissed. Good. Andre' From giuseppe.dangelo at kdab.com Mon Mar 27 21:36:18 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 27 Mar 2017 21:36:18 +0200 Subject: [Development] QList In-Reply-To: <20170327192500.GA3047@klara.mpi.htwm.de> References: <710d0e9a324012550a1eb69984a8029c@kdab.com> <201703270855.53949.marc.mutz@kdab.com> <20170327190355.GA2948@klara.mpi.htwm.de> <88b6ebc5-1de0-36a3-db26-5c5dcb18acbb@kdab.com> <20170327192500.GA3047@klara.mpi.htwm.de> Message-ID: Il 27/03/2017 21:25, André Pönitz ha scritto: > So that was after the argument of QList being used for a decade by Qt users > was dismissed. > > Good. Sorry, what are we talking about now? The "QList" name, QList as a class/technology, QList usage in Qt public APIs, ...? -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Mon Mar 27 22:54:16 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Mar 2017 13:54:16 -0700 Subject: [Development] QList In-Reply-To: References: <88b6ebc5-1de0-36a3-db26-5c5dcb18acbb@kdab.com> Message-ID: <8832244.AF9dW8bYdS@tjmaciei-mobl1> On segunda-feira, 27 de março de 2017 12:19:38 PDT Scott Aron Bloom wrote: > My two bits, as a 15+ year Qt professional level user, and semi-active > qt-list person, who is on this list to see whats going on, but doesn’t have > much time to actively develop... Sometimes called a whiner 😊 > Calling it a "List" is wrong...it does imply linked list... If you wanted to > have two "vectors" of different levels of optimization, QArray and QVector > would have been my preference. Well, of the 5 Qt major versions, none of them had "list implies linked list". Qt2 and 3 had a linked list called QValueList, but Qt2's class called QList was something worse: it was a linked list of pointers to the object. That became QPtrList in Qt 3, which freed up the name to make QList in Qt4 that inherited the original Qt behaviour of pointer to the object, but dropped the linked part. Since QList is the most commonly used container in Qt, we couldn't keep it as a linked list. If you want a linked list, there's QLinkedList. > As somone who lived through the Qt 3->4 pain, (and who as a consultant > helped 30+ projects do the conversion), it was painful. But not because of > the naming, mostly because of lost functionality that didn’t exist until > Graphics View came back To be honest, I forget which "view" Qt3 used that > had to wait until Qt4's QGraphicsView was of full quality. That was QCanvas (Q3Canvas). > If it were up to me.. I would love to see Qt focus on containers that Qt > MUST have that add SIGNIFICANT value to the Qt world, NOT "well when we > started, there was no stl" version. For instance, I do see the value of > QString for translation in the Qt world. Others may disagree, but QList > std::list or std::vector, or QSet, makes NO sense to me for Qt to keep. The argument isn't about there being an alternative, it's that the alternative isn't suitable because it's easy to get wrong. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Mar 27 22:56:56 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Mar 2017 13:56:56 -0700 Subject: [Development] QList In-Reply-To: References: <2867454.cgdXHHexsp@tjmaciei-mobl1> Message-ID: <2326513.bVaUqlHFvg@tjmaciei-mobl1> On segunda-feira, 27 de março de 2017 11:14:24 PDT Giuseppe D'Angelo wrote: > If we can't make it an alias, can we start adding extra functions for > the various QStringRef *ref() methods (in QXmlStreamReader, > QRegularExpressionMatch, probably elsewhere too), returning QStringView? Never return QStringView in our API. It's as bad as returning a const reference. In fact, that's a good rule of thumb: if you could have used a const QString & in that function, you can use QStringView. Otherwise, return QString by value. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From giuseppe.dangelo at kdab.com Mon Mar 27 23:53:05 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 27 Mar 2017 23:53:05 +0200 Subject: [Development] QList In-Reply-To: <2326513.bVaUqlHFvg@tjmaciei-mobl1> References: <2867454.cgdXHHexsp@tjmaciei-mobl1> <2326513.bVaUqlHFvg@tjmaciei-mobl1> Message-ID: Il 27/03/2017 22:56, Thiago Macieira ha scritto: > On segunda-feira, 27 de março de 2017 11:14:24 PDT Giuseppe D'Angelo wrote: >> If we can't make it an alias, can we start adding extra functions for >> the various QStringRef *ref() methods (in QXmlStreamReader, >> QRegularExpressionMatch, probably elsewhere too), returning QStringView? > > Never return QStringView in our API. It's as bad as returning a const > reference. > > In fact, that's a good rule of thumb: if you could have used a const QString & > in that function, you can use QStringView. Otherwise, return QString by value. Why should it bad if what you want return is precisely a "const reference" over QString-like data? Isn't that the whole reason why we have functions returning QStringRef right now (lacking a QStringView)? (And also the reason why QStringView itself returns QStringViews?) Example of use case: a tokenizer operating over QString-like data, returning each token as a QStringView, with no memory allocations -- possibly even noexcept (narrow contract on the source string). Why would I want to return QStrings for this use case and super-pessimize it? Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From rafael.roquetto at kdab.com Tue Mar 28 00:05:32 2017 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Mon, 27 Mar 2017 19:05:32 -0300 Subject: [Development] OT: English phonetic spelling (was: QList) In-Reply-To: <9b9bf0af2fd66697bf9eaeebd112d7c3.squirrel@squirrel.six.silmor.de> References: <201703270855.53949.marc.mutz@kdab.com> <201703270943.57221.marc.mutz@kdab.com> <58D93334.4040306@gmail.com> <9b9bf0af2fd66697bf9eaeebd112d7c3.squirrel@squirrel.six.silmor.de> Message-ID: <20170327220530.GB7333@orion> On Mon, Mar 27, 2017 at 06:44:16PM +0200, Konrad Rosenbaum wrote: > [quite OT, but I'll pile on... - just for fun] > > > Yes, German is almost completely phonetic - except for very few loan words > that have not completely assimilated yet. But there are efforts under way > to send them on an integration and language course, now that they've > gained asylum and are proven to be mostly harmless. Sorry for being pedantic, but as someone who struggled to learn German, this is not entirely true. English is not a good ruler to measure against. German is only true phonetic when sung by Rammstein :P -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3599 bytes Desc: not available URL: From rafael.roquetto at kdab.com Tue Mar 28 00:18:18 2017 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Mon, 27 Mar 2017 19:18:18 -0300 Subject: [Development] QList In-Reply-To: References: <2b79c7ff-8cbd-f80f-9df7-2026690a709d@kdab.com> <20170327130551.2B18.6F0322A@gmail.com> <0eba1dd8-bfb2-f2e2-d028-e90bffab3621@kdab.com> Message-ID: <20170327221817.GC7333@orion> On Mon, Mar 27, 2017 at 11:47:36AM +0000, Martin Smith wrote: > > I'm not even counting the argument from authority when > >CS/Math were brought to the table without an invitation > > > I will keep bringing them to the table because, as a documentation guy following this and other similar discussions, it looks like you (plural) are willing to ignore the importance of naming things in the API because of technical problems with implementations in C++. I would like to just highlight the a informal fallacy of redefinition I have seen in this thread. Some people are talking apples + oranges here. A lot of people who speak C will use the word vector interchangeably with the word 'array'. You don't need to go much farther: in C++, without further context, a vector clearly means std::vector (but could still mean the same as an array, or even QVector, depending on the context). It clearly has nothing to do anymore with the vector from my geometry classes. I don't know why it received the named 'vector' in first place, but I am willing to bet this is the derivation that some people in linguistics call a 'dead metaphor' (except that the original vector is still alive). It happens all the time in the evolution of languages. A good example by Guy Deutscher: "“Thrill” “Goes back to an old English verb “thryllian” which originally meant pierce. The current sense of “thrill” must have started out as a metaphor with some shock value: “I’m thrilled to bits” must have been a graphic equivalent of today’s “it’s killing”." Just my two cents. > > ________________________________ > From: Development on behalf of Giuseppe D'Angelo > Sent: Monday, March 27, 2017 1:35:20 PM > To: development at qt-project.org > Subject: Re: [Development] QList > > Il 27/03/2017 13:05, Philippe ha scritto: > > QPolygon needs not be a QVector > > QPolygon can be a QVector > > QPolygon can be a QList > > ... which confirms the fallacy. > > > > > ...but *today*, QPolygon is "implemented as a QVector" > > Hence from the OO common dialect, QPolygon is-a QVector > > This subthread wasn't arguing with that (and you've already got an > answer about why "implemented as a QVector" was a bad idea), but with > the formal fallacies in the arguments exposed so far (four in four > messages, and I'm not even counting the argument from authority when > CS/Math were brought to the table without an invitation). > > Cheers, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 > KDAB - Qt, C++ and OpenGL Experts > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3599 bytes Desc: not available URL: From jani.heikkinen at qt.io Tue Mar 28 06:21:41 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 28 Mar 2017 04:21:41 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: <10813507.0tU7pd7eKk@tjmaciei-mobl1> References: <10813507.0tU7pd7eKk@tjmaciei-mobl1> Message-ID: > > Sounds good, but please remember we'll need to keep at least the source > tarballs for each and every beta and RC that we release. > Yeah, that's OK > Maybe every week is too aggressive, since few people will test every week > and give feedback in time for the next release. We may find that every other > week is better. Yes, the goal is to have new beta n about week or two after previous one, pretty much when we have important fixes in & when we have managed to create content and verified that to be good enough. The main idea is that we won't do new release from each successfully qt5.git integration by default but still do several beta releases quite regularly (kind of need basis). br, Jani From marc.mutz at kdab.com Tue Mar 28 06:48:21 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 28 Mar 2017 06:48:21 +0200 Subject: [Development] QList In-Reply-To: References: <2326513.bVaUqlHFvg@tjmaciei-mobl1> Message-ID: <201703280648.22306.marc.mutz@kdab.com> On Monday 27 March 2017 23:53:05 Giuseppe D'Angelo wrote: > Why would > I want to return QStrings for this use case and super-pessimize it? You wouldn't. You can return QStringViews just as well as you can take an iterator into a collection. Whether a give QStringRef return is safe to be replaced with QStringView is another matter, one that needs to be evaluated case-by-case. A blanket statement is not possible, since QStringRef has stronger stability guarantees (probably undocumented, though). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Tue Mar 28 07:01:51 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Mar 2017 22:01:51 -0700 Subject: [Development] QList In-Reply-To: References: <2326513.bVaUqlHFvg@tjmaciei-mobl1> Message-ID: <1644566.2453LE8ybp@tjmaciei-mobl1> On segunda-feira, 27 de março de 2017 14:53:05 PDT Giuseppe D'Angelo wrote: > Why should it bad if what you want return is precisely a "const > reference" over QString-like data? Isn't that the whole reason why we > have functions returning QStringRef right now (lacking a QStringView)? > (And also the reason why QStringView itself returns QStringViews?) The functions returning QStringRef are not a good practice. They are bad API in the first place, so please don't make the situation worse. Now, replacing QStringRef with QStringView may be acceptable, as it makes the problem not much worse. But at least in the case of QXmlStreamReader, it does, so that won't work. > Example of use case: a tokenizer operating over QString-like data, > returning each token as a QStringView, with no memory allocations -- > possibly even noexcept (narrow contract on the source string). Why would > I want to return QStrings for this use case and super-pessimize it? Tht's probably acceptable. We need to study each case in a case-by-case basis. Rule of thumb is to return QString. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Mar 28 07:04:08 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Mar 2017 22:04:08 -0700 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: <10813507.0tU7pd7eKk@tjmaciei-mobl1> Message-ID: <2181678.5Vf6LiGfdI@tjmaciei-mobl1> On segunda-feira, 27 de março de 2017 21:21:41 PDT Jani Heikkinen wrote: > > Maybe every week is too aggressive, since few people will test every week > > and give feedback in time for the next release. We may find that every > > other week is better. > > Yes, the goal is to have new beta n about week or two after previous one, > pretty much when we have important fixes in & when we have managed to > create content and verified that to be good enough. The main idea is that > we won't do new release from each successfully qt5.git integration by > default but still do several beta releases quite regularly (kind of need > basis). My point is that weekly releases is too fast and will be confusing. People will be testing beta N, and reporting next week what they've found, only to run into people already testing beta N+1 and unable to reproduce the same situations. Maybe I'm wrong. The kernel does have weekly release candidates, so why not us? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Mar 28 07:31:34 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Mar 2017 22:31:34 -0700 Subject: [Development] QList In-Reply-To: <20170327221817.GC7333@orion> References: <20170327221817.GC7333@orion> Message-ID: <3729246.dljStE55Lu@tjmaciei-mobl1> On segunda-feira, 27 de março de 2017 15:18:18 PDT Rafael Roquetto wrote: > "“Thrill” > > “Goes back to an old English verb “thryllian” which originally meant pierce. þyrlian - http://bosworth.ff.cuni.cz/032433 þyrelian - http://bosworth.ff.cuni.cz/032427 I used to know a much better dictionary, but I can't find the link anymore... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Eike.Ziller at qt.io Tue Mar 28 08:02:39 2017 From: Eike.Ziller at qt.io (Eike Ziller) Date: Tue, 28 Mar 2017 06:02:39 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: <2181678.5Vf6LiGfdI@tjmaciei-mobl1> References: <10813507.0tU7pd7eKk@tjmaciei-mobl1> <2181678.5Vf6LiGfdI@tjmaciei-mobl1> Message-ID: <74CA7D94-60A6-4C1A-85E6-3FF3E97D6ADA@qt.io> > On Mar 28, 2017, at 07:04, Thiago Macieira wrote: > > On segunda-feira, 27 de março de 2017 21:21:41 PDT Jani Heikkinen wrote: >>> Maybe every week is too aggressive, since few people will test every week >>> and give feedback in time for the next release. We may find that every >>> other week is better. >> >> Yes, the goal is to have new beta n about week or two after previous one, >> pretty much when we have important fixes in & when we have managed to >> create content and verified that to be good enough. The main idea is that >> we won't do new release from each successfully qt5.git integration by >> default but still do several beta releases quite regularly (kind of need >> basis). > > My point is that weekly releases is too fast and will be confusing. People > will be testing beta N, and reporting next week what they've found, only to > run into people already testing beta N+1 and unable to reproduce the same > situations. Currently they run into people who are unable to reproduce the same situations in their own build from git, which then can only answer “fixed in git but you cannot test it without doing a custom build from there”. And for fixes that are related to the package build process itself even that is not possible. I think in a process that is supposed to take 8 weeks (from beta to final), waiting (at least) 2 weeks to be able to verify fixes is pretty long, so I think _aiming_ for once a week is a good idea at least worth trying. > Maybe I'm wrong. The kernel does have weekly release candidates, so why not > us? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From alexander.blasche at qt.io Tue Mar 28 08:09:27 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Tue, 28 Mar 2017 06:09:27 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: <10813507.0tU7pd7eKk@tjmaciei-mobl1>, Message-ID: >> Sounds good, but please remember we'll need to keep at least the source >> tarballs for each and every beta and RC that we release. > >Yeah, that's OK This implies that the user can identify the exact tag or version (aka beta 5) somewhere in the installer. Each bug report has to state this value. -- Alex From lars.knoll at qt.io Tue Mar 28 08:30:43 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 28 Mar 2017 06:30:43 +0000 Subject: [Development] QList In-Reply-To: <1644566.2453LE8ybp@tjmaciei-mobl1> References: <2326513.bVaUqlHFvg@tjmaciei-mobl1> <1644566.2453LE8ybp@tjmaciei-mobl1> Message-ID: <38F0324D-2933-41BE-8551-4E87E7660120@qt.io> > On 28 Mar 2017, at 07:01, Thiago Macieira wrote: > > On segunda-feira, 27 de março de 2017 14:53:05 PDT Giuseppe D'Angelo wrote: >> Why should it bad if what you want return is precisely a "const >> reference" over QString-like data? Isn't that the whole reason why we >> have functions returning QStringRef right now (lacking a QStringView)? >> (And also the reason why QStringView itself returns QStringViews?) > > The functions returning QStringRef are not a good practice. They are bad API > in the first place, so please don't make the situation worse. I agree in general, but there are valid exceptions. Parsers are one of those places where returning a QStringView with a documented lifetime (e.g. until your next call into the parser) is IMO a valid thing to do (since performance is critical here). > > Now, replacing QStringRef with QStringView may be acceptable, as it makes the > problem not much worse. But at least in the case of QXmlStreamReader, it does, > so that won't work. I guess that’s because of some issues in how the XmlStreamReader allocates (or re-allocates) it’s string. We should probably simply try to see how we can fix the implementation instead of saying that we can’t change the API to use QStringView. > >> Example of use case: a tokenizer operating over QString-like data, >> returning each token as a QStringView, with no memory allocations -- >> possibly even noexcept (narrow contract on the source string). Why would >> I want to return QStrings for this use case and super-pessimize it? > > Tht's probably acceptable. We need to study each case in a case-by-case basis. > > Rule of thumb is to return QString. By default, return values should be QString, I agree. Returning QStringView exposes more internals of the class. It does make sense in certain use cases though. Cheers, Lars From lars.knoll at qt.io Tue Mar 28 08:32:58 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 28 Mar 2017 06:32:58 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: <10813507.0tU7pd7eKk@tjmaciei-mobl1> Message-ID: > On 28 Mar 2017, at 08:09, Alex Blasche wrote: > > >>> Sounds good, but please remember we'll need to keep at least the source >>> tarballs for each and every beta and RC that we release. >> >> Yeah, that's OK > > This implies that the user can identify the exact tag or version (aka beta 5) somewhere in the installer. Each bug report has to state this value. Yes, either through a number or (preferable IMO) by simply putting the sha1 of qt5.git into a visible place. Cheers, Lars From lars.knoll at qt.io Tue Mar 28 08:36:23 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 28 Mar 2017 06:36:23 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: <2181678.5Vf6LiGfdI@tjmaciei-mobl1> References: <10813507.0tU7pd7eKk@tjmaciei-mobl1> <2181678.5Vf6LiGfdI@tjmaciei-mobl1> Message-ID: > On 28 Mar 2017, at 07:04, Thiago Macieira wrote: > > On segunda-feira, 27 de março de 2017 21:21:41 PDT Jani Heikkinen wrote: >>> Maybe every week is too aggressive, since few people will test every week >>> and give feedback in time for the next release. We may find that every >>> other week is better. >> >> Yes, the goal is to have new beta n about week or two after previous one, >> pretty much when we have important fixes in & when we have managed to >> create content and verified that to be good enough. The main idea is that >> we won't do new release from each successfully qt5.git integration by >> default but still do several beta releases quite regularly (kind of need >> basis). > > My point is that weekly releases is too fast and will be confusing. People > will be testing beta N, and reporting next week what they've found, only to > run into people already testing beta N+1 and unable to reproduce the same > situations. > > Maybe I'm wrong. The kernel does have weekly release candidates, so why not > us? I’m all for releasing often. I don’t think it’ll be confusing to our users. Using the maintenance tool, they’ll get notifications, and updating from one beta to the next should be straightforward and easy. The only thing required is that we clearly identify the version they are using somewhere, and ask for that version in the bug report. Updating often has the advantage that people will get bug fixes faster and especially can also verify them faster. Cheers, Lars From jani.heikkinen at qt.io Tue Mar 28 08:47:53 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 28 Mar 2017 06:47:53 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: <10813507.0tU7pd7eKk@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- > project.org] On Behalf Of Lars Knoll > Sent: tiistaina 28. maaliskuuta 2017 9.33 > To: Alex Blasche > Cc: Qt development mailing list > Subject: Re: [Development] Proposal to adjust release candidate process > > > > On 28 Mar 2017, at 08:09, Alex Blasche wrote: > > > > > >>> Sounds good, but please remember we'll need to keep at least the > >>> source tarballs for each and every beta and RC that we release. > >> > >> Yeah, that's OK > > > > This implies that the user can identify the exact tag or version (aka beta 5) > somewhere in the installer. Each bug report has to state this value. > > Yes, either through a number or (preferable IMO) by simply putting the sha1 > of qt5.git into a visible place. We were planning to use Beta N in installer UI as well as git tags. should be ok and it is following current ways of working br, Jani > > Cheers, > Lars > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Maurice.Kalinowski at qt.io Tue Mar 28 09:33:24 2017 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Tue, 28 Mar 2017 07:33:24 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: <10813507.0tU7pd7eKk@tjmaciei-mobl1> Message-ID: Releasing beta more frequently is a welcomed item, for sure. However, that implies that there is even more packages to test and what has not been discussed is the fact that there are not more people testing. For WinRT the situation has been that Olli and I needed to test winrt/winphone-(arm/x64)-msvc(2013/2015), and that at least once per week. As you can imagine, if you go through the testing matrix properly that's around half a day for one package with multiple packages per person. There is not much time left to do development and bug fixing. For other platform teams the situation is the same. This has the effect that you start to be more "flexible" in what you test and hence it is way easier for a bug to slip through. Certainly we want to avoid that, but have not tackled any way to do so. I remember that others volunteered to help with package testing. That surely would be welcomed, but also given the fact that Jani sends out testing requests fairly often and the response rate is zero / nada / null / nil since years, I doubt that will change as well. Preferrably I'd not like to spend again 50%+ of my time testing packages until summer, or even more once the 5.8.1 discussion comes up again. Maurice > -----Original Message----- > From: Development [mailto:development- > bounces+maurice.kalinowski=qt.io at qt-project.org] On Behalf Of Jani > Heikkinen > Sent: Tuesday, March 28, 2017 8:48 AM > To: Lars Knoll ; Alex Blasche > Cc: Qt development mailing list > Subject: Re: [Development] Proposal to adjust release candidate process > > > > -----Original Message----- > > From: Development [mailto:development- > bounces+jani.heikkinen=qt.io at qt- > > project.org] On Behalf Of Lars Knoll > > Sent: tiistaina 28. maaliskuuta 2017 9.33 > > To: Alex Blasche > > Cc: Qt development mailing list > > Subject: Re: [Development] Proposal to adjust release candidate > > process > > > > > > > On 28 Mar 2017, at 08:09, Alex Blasche wrote: > > > > > > > > >>> Sounds good, but please remember we'll need to keep at least the > > >>> source tarballs for each and every beta and RC that we release. > > >> > > >> Yeah, that's OK > > > > > > This implies that the user can identify the exact tag or version > > > (aka beta 5) > > somewhere in the installer. Each bug report has to state this value. > > > > Yes, either through a number or (preferable IMO) by simply putting the > > sha1 of qt5.git into a visible place. > > We were planning to use Beta N in installer UI as well as git tags. should be ok > and it is following current ways of working > > br, > Jani > > > > > > Cheers, > > Lars > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Tue Mar 28 11:44:01 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 28 Mar 2017 09:44:01 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: <10813507.0tU7pd7eKk@tjmaciei-mobl1> Message-ID: I don't see any more testing required with this new approach than earlier because earlier we created snapshots to be tested, now we will do additional betas. The thing which will change is the way we will do the testing: Earlier we need to wait until all packages were tested manually before release but with this new approach we rely on RTA. Manual testing will mostly start after the beta n release; if something is broken in the beta n it can be fixed in beta n+1 but still well before final release. br, Jani > -----Original Message----- > From: Maurice Kalinowski > Sent: tiistaina 28. maaliskuuta 2017 10.33 > To: Jani Heikkinen ; Lars Knoll ; Alex > Blasche > Cc: Qt development mailing list > Subject: RE: [Development] Proposal to adjust release candidate process > > Releasing beta more frequently is a welcomed item, for sure. > > However, that implies that there is even more packages to test and what has > not been discussed is the fact that there are not more people testing. > > For WinRT the situation has been that Olli and I needed to test > winrt/winphone-(arm/x64)-msvc(2013/2015), and that at least once per > week. As you can imagine, if you go through the testing matrix properly that's > around half a day for one package with multiple packages per person. There > is not much time left to do development and bug fixing. For other platform > teams the situation is the same. This has the effect that you start to be more > "flexible" in what you test and hence it is way easier for a bug to slip through. > Certainly we want to avoid that, but have not tackled any way to do so. > > I remember that others volunteered to help with package testing. That surely > would be welcomed, but also given the fact that Jani sends out testing > requests fairly often and the response rate is zero / nada / null / nil since > years, I doubt that will change as well. > > Preferrably I'd not like to spend again 50%+ of my time testing packages until > summer, or even more once the 5.8.1 discussion comes up again. > > > Maurice > > > > -----Original Message----- > > From: Development [mailto:development- > > bounces+maurice.kalinowski=qt.io at qt-project.org] On Behalf Of Jani > > Heikkinen > > Sent: Tuesday, March 28, 2017 8:48 AM > > To: Lars Knoll ; Alex Blasche > > > > Cc: Qt development mailing list > > Subject: Re: [Development] Proposal to adjust release candidate > > process > > > > > > > -----Original Message----- > > > From: Development [mailto:development- > > bounces+jani.heikkinen=qt.io at qt- > > > project.org] On Behalf Of Lars Knoll > > > Sent: tiistaina 28. maaliskuuta 2017 9.33 > > > To: Alex Blasche > > > Cc: Qt development mailing list > > > Subject: Re: [Development] Proposal to adjust release candidate > > > process > > > > > > > > > > On 28 Mar 2017, at 08:09, Alex Blasche > wrote: > > > > > > > > > > > >>> Sounds good, but please remember we'll need to keep at least the > > > >>> source tarballs for each and every beta and RC that we release. > > > >> > > > >> Yeah, that's OK > > > > > > > > This implies that the user can identify the exact tag or version > > > > (aka beta 5) > > > somewhere in the installer. Each bug report has to state this value. > > > > > > Yes, either through a number or (preferable IMO) by simply putting > > > the > > > sha1 of qt5.git into a visible place. > > > > We were planning to use Beta N in installer UI as well as git tags. > > should be ok and it is following current ways of working > > > > br, > > Jani > > > > > > > > > > Cheers, > > > Lars > > > > > > _______________________________________________ > > > Development mailing list > > > Development at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development From rafael.roquetto at kdab.com Tue Mar 28 13:56:19 2017 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Tue, 28 Mar 2017 08:56:19 -0300 Subject: [Development] QList In-Reply-To: <3729246.dljStE55Lu@tjmaciei-mobl1> References: <20170327221817.GC7333@orion> <3729246.dljStE55Lu@tjmaciei-mobl1> Message-ID: <20170328115618.GA5084@orion> On Mon, Mar 27, 2017 at 10:31:34PM -0700, Thiago Macieira wrote: > On segunda-feira, 27 de março de 2017 15:18:18 PDT Rafael Roquetto wrote: > > "“Thrill” > > > > “Goes back to an old English verb “thryllian” which originally meant pierce. > > þyrlian - http://bosworth.ff.cuni.cz/032433 > þyrelian - http://bosworth.ff.cuni.cz/032427 > > I used to know a much better dictionary, but I can't find the link anymore... Groovy! For etymology wikitionary is usually my starting point, and then usually I follow up on etymonline.com - I had no idea about this OE dict. Thanks for sharing! -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3599 bytes Desc: not available URL: From krnekit at gmail.com Tue Mar 28 21:48:05 2017 From: krnekit at gmail.com (Nikita Krupenko) Date: Tue, 28 Mar 2017 22:48:05 +0300 Subject: [Development] QList In-Reply-To: <20170327221817.GC7333@orion> References: <20170327221817.GC7333@orion> Message-ID: <1620980.CWr1kT3EmB@localhost.localdomain> On вторник, 28 марта 2017 г. 01:18:18 EEST Rafael Roquetto wrote: > It > clearly has nothing to do anymore with the vector from my geometry classes. > I don't know why it received the named 'vector' in first place, but I am > willing to bet this is the derivation that some people in linguistics call > a 'dead metaphor' (except that the original vector is still alive). I think, it came not from the geometr, but from the linear algebra, where vector is a m x 1 or 1 x m matrix. https://en.wikipedia.org/wiki/Row_and_column_vectors From marc.mutz at kdab.com Wed Mar 29 09:37:04 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 29 Mar 2017 09:37:04 +0200 Subject: [Development] QList In-Reply-To: <201703202302.23366.marc.mutz@kdab.com> References: <201703181051.07307.marc.mutz@kdab.com> <201703202302.23366.marc.mutz@kdab.com> Message-ID: <201703290937.05395.marc.mutz@kdab.com> To bring this thread back on-topic: I have prepared a patch that implements QArrayList as outlined below (as a template alias): https://codereview.qt-project.org/188938 The only well-known user of stable references into QList, QToolBox, is "ported" here: https://codereview.qt-project.org/188941 Please approve the former, or propose something else. If we go with QArrayList, the next question is whether we use it in code that has been proven to require stability of references (only possible when you know the code!) or wherever QList _currently_ provides stable references on all platforms (QList: no; QList: yes). The latter might be necessary to support code we don't know, ie. user code, ie. in our APIs. I actually don't really intend to merge the latter, because Kevin said he'd look into porting that one away from QList (note: I didn't say "promised"), and I still have hope. Thanks, Marc On Monday 20 March 2017 23:02:22 Marc Mutz wrote: > On Saturday 18 March 2017 10:51:06 Marc Mutz wrote: > > 4. Provide QArrayList for code that needs stability of references > > (stability statically checked in Qt 5, enforced in Qt 6). > > There's disagreement over this last part. I have opted to provide a > constrained type alias QArrayList that can only be used to alias QLists > that already use QListData::IndirectLayout (= pointers to heap-allocated > objects). > > The intent was to allow QArrayList use in existing API. E.g., and I'm not > sure I'm proposing this, QList could be renamed to > QArrayList because it currently is. And some users may have come > to depend on the stability-of-references feature provided by inefficient > QLists. > > A type alias makes this trivial, because it introduces neither SC nor BC. > It's simply a way to document, and statically check, that that particular > QList has IndirectLayout. > > The other option would be to copy QList, strip out the optimisation that > makes it use layouts other than IndirectLayout and call the result > QArrayList. > > Disadvantages: > > - migration of QLists used in APIs has to wait until Qt 6 > - two almost identical code bases that are very likely to get out of sync, > accidentally or intentionally, before one of them gets ditched in Qt 6 > - duplicate documentation to write, maintain, explain difference, ... > With the type alias, we just need to document the alias. > > So, updated and refined tail of QList exit strategy would be: > > 4. Provide a type alias, QArrayList, for QList, constrained on actually > QListData::IndirectLayout QLists. Use it to mark QList uses that either > a. are (includes QVariant, QModelIndex, QImage, QPixmap, ...) > b. should conceptually be (excludes QVariant, QModelIndex, ...) > array lists (ie. arrays of pointers to heap-allocated objects) in a BC > and SC way. > > In Qt 6: (the -5- and -6- just refer to the Qt 5 and Qt 6 versions of the > names): > > 5. Q5List -> Q6ArrayList, strip out non-IndirectLayout code, making it > always use IndirectLayout. > 6. Provide a deprecated type alias Q6List that resolves to either Q6Vector > or Q6ArrayList, depending on similar conditions Q5List used before. 7. > Replace all Q6List uses in API with either Q6ArrayList or Q6Vector. > > Advantages: > > - only one QList implementation to maintain and document in both Qt 5 and > 6. - adjustable SC: > > Because this introduces a SiC/SC knob that's interesting to turn: > > If Q6List uses the exact same conditions as Q5List, Q6List would > have the same layout as Q5List, making 'QList' SC. But > Q6List would map to Q6ArrayList while the Qt API very > probably will have migrated to Q6Vector, making 'QList' > SiC. > > If we, say, dropped the isLarge trait from the condition, then some > Q6List would switch memory layout, breaking stability of > references for some UserTypes, compared to Q5List, making > 'QList' SiC. But Q6List would map to > Q6Vector, making 'QList', QList etc. SC. > > Not sure where that knob will end up, but it's nice that it's there. > > Thanks, > Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Wed Mar 29 10:29:57 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 29 Mar 2017 10:29:57 +0200 Subject: [Development] QList In-Reply-To: <201703290937.05395.marc.mutz@kdab.com> References: <201703202302.23366.marc.mutz@kdab.com> <201703290937.05395.marc.mutz@kdab.com> Message-ID: <201703291029.57727.marc.mutz@kdab.com> On Wednesday 29 March 2017 09:37:04 Marc Mutz wrote: > Please approve the former, or propose something else. I actually meant this ^^. Approve or _propose_ something else. Just to be clear on this: I'm ready to do the work as outlined. But I will most certainly not write a QArrayList-as-a-class-in-Qt-5 that supports QArrayList. IMO, QArrayList is a marker for the Qt 5->6 transition. It is not a cool new Qt container class. In fact, if I was to decide, I'd deprecate QArrayList on the spot in Qt 6 and remove it in Qt 7. If you want a QArrayList, write it yourself. Well, or use vector>. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From olivier at woboq.com Wed Mar 29 10:39:42 2017 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 29 Mar 2017 10:39:42 +0200 Subject: [Development] QList In-Reply-To: <201703290937.05395.marc.mutz@kdab.com> References: <201703202302.23366.marc.mutz@kdab.com> <201703290937.05395.marc.mutz@kdab.com> Message-ID: <1754264.rmNIGM7Dej@maurice> On Mittwoch, 29. März 2017 09:37:04 CEST Marc Mutz wrote: > To bring this thread back on-topic: > > I have prepared a patch that implements QArrayList as outlined below (as a > template alias): https://codereview.qt-project.org/188938 > > The only well-known user of stable references into QList, QToolBox, is > "ported" here: https://codereview.qt-project.org/188941 > > Please approve the former, or propose something else. I don't think we need QArrayList. As you said, it's not often used (only one known use?). and QToolBox is not even using the implicit sharing, so it could easily be ported so std::vector> -> https://codereview.qt-project.org/189967 Having this alias does not bring much. It's not a real class, I can't use it with QArrayList From edward.welbourne at qt.io Wed Mar 29 11:17:31 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 29 Mar 2017 09:17:31 +0000 Subject: [Development] Etymological digression from QList discussion In-Reply-To: <1620980.CWr1kT3EmB@localhost.localdomain> References: <20170327221817.GC7333@orion>, <1620980.CWr1kT3EmB@localhost.localdomain> Message-ID: On вторник, 28 марта 2017 г. 01:18:18 EEST Rafael Roquetto wrote: >> It clearly has nothing to do anymore with the vector from my geometry >> classes. I don't know why it received the named 'vector' in first >> place, It's "carrier" in Latin; a vector carries several numbers. Geometry was a late-comer to using vectors. Physicists studying field theory first developed them, in the 1800s, starting from the quaternions. >> but I am willing to bet this is the derivation that some >> people in linguistics call a 'dead metaphor' (except that the >> original vector is still alive). Not sure what you imagine your metaphor was. You might have a better case for matrix (see below). Nikita Krupenko (28 March 2017 21:48) > I think, it came not from the geometr, but from the linear algebra, where > vector is a m x 1 or 1 x m matrix. > > https://en.wikipedia.org/wiki/Row_and_column_vectors Well, "matrix" comes from the Latin for mother, rather indirectly; early industrial revolution metal-working involved stamping sheets of metal between a matrix and a patrix (from father - I will not elaborate on the metaphor at work here) to form it into shapes; a matrix is a pattern establishing a form. Its usage got diversified from there and patrix vanished. Grids of numbers got described using the same word (the grid is the pattern); but (rank 1) "vectors" were distinguished from (rank > 1) "matrices" in early linear algebra. Linear algebra has moved on from vectors being columns (or rows) of numbers - as I said before, anything you know how to add to similar things and scale by numbers is a vector; and this does include linear maps between vector spaces, which are what matrices represent. The notation is very convenient, but seduces some misunderstandings that I'll try not to digress into here ... Vectors are handy for describing geometry. Euclidean geometry didn't use them (it had a well-established notation already) until the notation was relatively mature; but the theory of smooth manifolds (which is the world of curved geometry) has little option but to deal with abstract vectors (as distinct from the columns of numbers that represent them), covectors (rows) and linear maps (represented by matrices) along with a whole panoply of co-ordinate-independence analysis. But I think this is more than enough on the subject of where the word "vector" comes from; for the purposes of software, a vector is a sequential collection (with array-like connotations); and the tortuous path by which that came to be so is beside the point, Eddy. From ville.voutilainen at gmail.com Wed Mar 29 11:37:57 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 29 Mar 2017 12:37:57 +0300 Subject: [Development] QList In-Reply-To: <201703291029.57727.marc.mutz@kdab.com> References: <201703202302.23366.marc.mutz@kdab.com> <201703290937.05395.marc.mutz@kdab.com> <201703291029.57727.marc.mutz@kdab.com> Message-ID: On 29 March 2017 at 11:29, Marc Mutz wrote: > On Wednesday 29 March 2017 09:37:04 Marc Mutz wrote: >> Please approve the former, or propose something else. > > I actually meant this ^^. Approve or _propose_ something else. > > Just to be clear on this: I'm ready to do the work as outlined. But I will > most certainly not write a QArrayList-as-a-class-in-Qt-5 that supports > QArrayList. > > IMO, QArrayList is a marker for the Qt 5->6 transition. It is not a cool new > Qt container class. In fact, if I was to decide, I'd deprecate QArrayList on > the spot in Qt 6 and remove it in Qt 7. > > If you want a QArrayList, write it yourself. Well, or use > vector>. Let me take a step back. Do we need a list container that is always indirect regardless of the element type and uses implicit sharing? If I start using QArrayList today, and it's immediately deprecated, what should I use instead? vector>? That doesn't do implicit sharing, so I can't pass it by value into slots. From marc.mutz at kdab.com Wed Mar 29 11:49:32 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 29 Mar 2017 11:49:32 +0200 Subject: [Development] Wishes for C++ standard or compilers In-Reply-To: <5144126.lprWczEdJB@tjmaciei-mobl1> References: <14194925.OZWiO3H5W7@tjmaciei-mobl1> <5144126.lprWczEdJB@tjmaciei-mobl1> Message-ID: <201703291149.33049.marc.mutz@kdab.com> On Monday 20 March 2017 22:19:11 Thiago Macieira wrote: > Em sábado, 18 de março de 2017, às 14:20:49 PDT, Thiago Macieira escreveu: > > == Containers == > > > > And then there's what to do with the containers. Here's where Marc's > > opinion and mine differ considerably. Aside from the need to maintain > > source compatibility, I feel like we should keep our containers and keep > > implicit sharing (same solution as for QString). We know COW can be a > > pessimisation for performance-sentive code, but the question is whether > > it is so for regular developers who don't know how to write > > performance-sensitive code. If developers will make mistakes, can we > > reduce the impact? > > Here's another wish that I remembered: destructive move a.k.a. relocation. > > The destructive move is a special case of move in which the source is also > detroyed in the process, as opposed to the regular move in which its > contents get moved but the destructor is still called and the object is > still in a valid (but unspecified) state. > > Then we have an even more special case of destructive move: trivial > destructive move (trivial relocation), which is just a memcpy. A type with > trivial move constructor and trivial destructor is trivially relocatable > too, since the trivial destructor does nothing and the trivial move > constructor is memcpy. However, the trick is to implement the relocation > for non-trivial types. > > Note that this needs the discussion on the lifetime of trivial types to be > finished. +1 This is probably one of the most important things. Ville asked on std- proposals to show hard numbers. You don't need hard numbers. You just need to superficially look at QVector. The compiler generally cannot proove that the call to QArrayData::deallocate() can be dropped from the QString dtor. It will always emit the atomic lock;sub and the call to deallocate(), even though the move ctor is inline and sets the d-pointer to sharedNull(). I have tried many things over the past year or so, incl. Q_ASSUME(!ref == -1) in sharedNull() and explicitly checking for that same condition in the QString dtor. It just doesn't help. This is an example of the WTF missed-optimisation that Chandler presented at MeetingC++ 2016: https://www.youtube.com/watch?v=s4wnuiCwTGU Only difference: we need it for thousands of items, not just four. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From ville.voutilainen at gmail.com Wed Mar 29 11:53:16 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 29 Mar 2017 12:53:16 +0300 Subject: [Development] Wishes for C++ standard or compilers In-Reply-To: <201703291149.33049.marc.mutz@kdab.com> References: <14194925.OZWiO3H5W7@tjmaciei-mobl1> <5144126.lprWczEdJB@tjmaciei-mobl1> <201703291149.33049.marc.mutz@kdab.com> Message-ID: On 29 March 2017 at 12:49, Marc Mutz wrote: > This is probably one of the most important things. Ville asked on std- > proposals to show hard numbers. You don't need hard numbers. You just need to > superficially look at QVector. The compiler generally cannot proove > that the call to QArrayData::deallocate() can be dropped from the QString > dtor. It will always emit the atomic lock;sub and the call to deallocate(), > even though the move ctor is inline and sets the d-pointer to sharedNull(). I > have tried many things over the past year or so, incl. Q_ASSUME(!ref == -1) in > sharedNull() and explicitly checking for that same condition in the QString > dtor. It just doesn't help. > > This is an example of the WTF missed-optimisation that Chandler presented at > MeetingC++ 2016: https://www.youtube.com/watch?v=s4wnuiCwTGU > > Only difference: we need it for thousands of items, not just four. The hard number we still need is this: 1) how much of a performance difference does a destructive move make The softer numbers we need are these: a) how many types benefit from it b) how often are those types used c) what are the practical performance improvements, assuming that the hard number (1) gave us a benchmark number. If "you don't need hard numbers", be prepared to live with a C++ that doesn't have a destructive move. Assuming that everyone in the committee finds its motivation obviously sound is a losing strategy, as is assuming that many people in the committee are aware of how destructive move helps implicit-sharing containers. From marc.mutz at kdab.com Wed Mar 29 13:26:21 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 29 Mar 2017 13:26:21 +0200 Subject: [Development] QList In-Reply-To: References: <201703291029.57727.marc.mutz@kdab.com> Message-ID: <201703291326.21608.marc.mutz@kdab.com> On Wednesday 29 March 2017 11:37:57 Ville Voutilainen wrote: > On 29 March 2017 at 11:29, Marc Mutz wrote: > > On Wednesday 29 March 2017 09:37:04 Marc Mutz wrote: > >> Please approve the former, or propose something else. > > > > I actually meant this ^^. Approve or _propose_ something else. > > > > Just to be clear on this: I'm ready to do the work as outlined. But I > > will most certainly not write a QArrayList-as-a-class-in-Qt-5 that > > supports QArrayList. > > > > IMO, QArrayList is a marker for the Qt 5->6 transition. It is not a cool > > new Qt container class. In fact, if I was to decide, I'd deprecate > > QArrayList on the spot in Qt 6 and remove it in Qt 7. > > > > If you want a QArrayList, write it yourself. Well, or use > > vector>. > > Let me take a step back. Do we need a list container that is always > indirect regardless of > the element type and uses implicit sharing? > > If I start using QArrayList today, and it's immediately > deprecated, what > should I use instead? vector>? That doesn't > do implicit sharing, Because it's you who asks: if CoW is so super-important, why did the committee drop support for CoWed std::string in C++11? That brings us straight back to the fundamental question: Why can the C++ world at large cope with containers that are not CoW and Qt cannot? The only answer I have is "because Qt never tried". And that's the end of it. I have pointed to Herb's string measurements from a decade or two ago. I have shown that copying a std::vector up to 1K ints is faster than a QVector, when hammered by at least two threads. It's not even clear, yet, whether Q6String will have SSO. The insistance to ignore two decades of advances in computer science combined with a habit to reinforce bad practices just because "we've always done so" (I just had to review _another_ pimpl'ed class that contained nothing but two enums) by having all the good stuff as an opt-in that no-one uses, is slowly getting on my nerves. I can't win this argument, because here, too, we're facing post-factual discussions. When you argue that QList is a bad default container, people come and say that sorting a QList of std::array<1024> is faster than a QVector of the same type, or other corner cases like: > so I can't pass it by value into slots. Why would you want to? No-one does that. People use cref, like for all large types. Qt makes sure that a copy is taken only when needed, ie. when the slot is in a different thread from the emitter. That is very rare, and people can be expected to pass a shared_ptr instead in these situations. Bottomline: don't expect me to support any form of implicit sharing. The answer will always be: because you should use explicit sharing. This is why I see QArrayList as a phase-out vehicle for QList, not as a fancy new container. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Wed Mar 29 13:27:46 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 29 Mar 2017 13:27:46 +0200 Subject: [Development] QList In-Reply-To: References: <201703291029.57727.marc.mutz@kdab.com> Message-ID: <201703291327.47031.marc.mutz@kdab.com> On Wednesday 29 March 2017 11:37:57 Ville Voutilainen wrote: > Let me take a step back. Do we need a list container that is always > indirect regardless of > the element type and uses implicit sharing? We have that: it's called QLinkedList. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From philwave at gmail.com Wed Mar 29 13:33:12 2017 From: philwave at gmail.com (Philippe) Date: Wed, 29 Mar 2017 13:33:12 +0200 Subject: [Development] QList In-Reply-To: <1754264.rmNIGM7Dej@maurice> References: <201703290937.05395.marc.mutz@kdab.com> <1754264.rmNIGM7Dej@maurice> Message-ID: <20170329133311.BE17.6F0322A@gmail.com> On Wed, 29 Mar 2017 10:39:42 +0200 Olivier Goffart wrote: > I don't think we need QArrayList. As you said, it's not often used (only one > known use?). and QToolBox is not even using the implicit sharing, so it could > easily be ported so std::vector> When you need an index-based container, to insert and sort many big objects, a QList like container is ideal. Easier than std::vector> and with the benefit of cow. Philippe From ville.voutilainen at gmail.com Wed Mar 29 13:39:34 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 29 Mar 2017 14:39:34 +0300 Subject: [Development] QList In-Reply-To: <201703291326.21608.marc.mutz@kdab.com> References: <201703291029.57727.marc.mutz@kdab.com> <201703291326.21608.marc.mutz@kdab.com> Message-ID: On 29 March 2017 at 14:26, Marc Mutz wrote: >> If I start using QArrayList today, and it's immediately >> deprecated, what >> should I use instead? vector>? That doesn't >> do implicit sharing, > > Because it's you who asks: if CoW is so super-important, why did the committee > drop support for CoWed std::string in C++11? Because they don't have cross-thread signals that need to sometimes copy the value. :) >> so I can't pass it by value into slots. > > Why would you want to? No-one does that. People use cref, like for all large > types. Qt makes sure that a copy is taken only when needed, ie. when the slot > is in a different thread from the emitter. That is very rare, and people can > be expected to pass a shared_ptr instead in these situations. Right. I can't use a vector> universally, I need to use a shared_ptr>> for signal cases. That's not very user-friendly any more. > Bottomline: don't expect me to support any form of implicit sharing. The > answer will always be: because you should use explicit sharing. > > This is why I see QArrayList as a phase-out vehicle for QList, not as a fancy > new container. All this makes me wonder why we should have QArrayList at all. If it's slated for immediate deprecation, we perhaps should never let it out, and just tell people to use QVector or QLinkedList instead of QList. From philwave at gmail.com Wed Mar 29 13:52:20 2017 From: philwave at gmail.com (Philippe) Date: Wed, 29 Mar 2017 13:52:20 +0200 Subject: [Development] QList In-Reply-To: <201703291326.21608.marc.mutz@kdab.com> References: <201703291326.21608.marc.mutz@kdab.com> Message-ID: <20170329135219.BE1B.6F0322A@gmail.com> > That brings us straight back to the fundamental question: Why can the C++ > world at large cope with containers that are not CoW and Qt cannot? The only > answer I have is "because Qt never tried". I started using STL 20 years ago, and Qt 8 years ago. Both intensively. My experience is simple: unless performance is the priority (5% of the cases?), the convenience of Qt COW containers outclasses the "convenience" of STL containers. Value-semantics is optimally implemented with implicitly shared containers. And IMHO, a strengh of Qt. Philippe From cavendish.qi at gmail.com Wed Mar 29 14:03:42 2017 From: cavendish.qi at gmail.com (Liang Qi) Date: Wed, 29 Mar 2017 14:03:42 +0200 Subject: [Development] Who's responsible for 3rdparty these days (QTBUG-59586)? In-Reply-To: <1923287.X8lTtAKxnU@tjmaciei-mobl1> References: <1923287.X8lTtAKxnU@tjmaciei-mobl1> Message-ID: On 19 March 2017 at 20:01, Thiago Macieira wrote: > The rules are that only Qt Company people can import 3rdparty code, so I > know > I am not responsible. > > Who do I assign the bug to? > https://bugreports.qt.io/browse/QTBUG-59586 For QTBUG-59586, I have https://codereview.qt-project.org/189977 and https://github.com/liangqi/zlib/tree/qt . Please give some feedback. And I still have a general question: I have seen this new git submodule way in qtlocation, like http://code.qt.io/cgit/qt/qtlocation-mapboxgl.git/ . So should we do a mirror in code.qt.io first and then add this in the modules? And there is common procedure for this purpose? for example, patches and qt_attribution.json file if upstream doesn't have it. Best Regards, Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Wed Mar 29 14:09:11 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 29 Mar 2017 14:09:11 +0200 Subject: [Development] QList In-Reply-To: <20170329133311.BE17.6F0322A@gmail.com> References: <201703290937.05395.marc.mutz@kdab.com> <1754264.rmNIGM7Dej@maurice> <20170329133311.BE17.6F0322A@gmail.com> Message-ID: <201703291409.11624.marc.mutz@kdab.com> On Wednesday 29 March 2017 13:33:12 Philippe wrote: > On Wed, 29 Mar 2017 10:39:42 +0200 > > Olivier Goffart wrote: > > I don't think we need QArrayList. As you said, it's not often used (only > > one known use?). and QToolBox is not even using the implicit sharing, so > > it could easily be ported so std::vector> > > When you need an index-based container, to insert and sort many big > objects, a QList like container is ideal. ^ as if on cue -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From giuseppe.dangelo at kdab.com Wed Mar 29 14:20:42 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Wed, 29 Mar 2017 14:20:42 +0200 Subject: [Development] QList In-Reply-To: <201703291327.47031.marc.mutz@kdab.com> References: <201703291029.57727.marc.mutz@kdab.com> <201703291327.47031.marc.mutz@kdab.com> Message-ID: <7b738e2e-2689-ca56-9bc6-e498174429d8@kdab.com> Il 29/03/2017 13:27, Marc Mutz ha scritto: > On Wednesday 29 March 2017 11:37:57 Ville Voutilainen wrote: >> Let me take a step back. Do we need a list container that is always >> indirect regardless of >> the element type and uses implicit sharing? > > We have that: it's called QLinkedList. Or, fixing QVector so that QVector> becomes supported. My 2c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From marc.mutz at kdab.com Wed Mar 29 14:31:50 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 29 Mar 2017 14:31:50 +0200 Subject: [Development] QList In-Reply-To: References: <201703291326.21608.marc.mutz@kdab.com> Message-ID: <201703291431.51173.marc.mutz@kdab.com> On Wednesday 29 March 2017 13:39:34 Ville Voutilainen wrote: > > Bottomline: don't expect me to support any form of implicit sharing. The > > answer will always be: because you should use explicit sharing. > > > > This is why I see QArrayList as a phase-out vehicle for QList, not as a > > fancy new container. > > All this makes me wonder why we should have QArrayList at all. If it's > slated for immediate deprecation, I said _I_ would immediately deprecate it. Wether we do depends on a lot of other things, too. E.g. what will happen to our other containers. > we perhaps should never let it out, and just tell people to use > QVector or QLinkedList instead of QList. It's part of the QList exit strategy. Q6ArrayList will be one and Q6Vector the other implementation underlying Q6List, which then will be the template alias that contains the std::conditional that we currently have inside QList. We can't make QLinkedList the other implementation beside QVector, since QLinkedList does not provide an efficient index-based API (even though Qt tried that, too: http://doc.qt.io/qt-4.8/q3valuelist.html). Like the Q3ValueList in that link, it's a vehicle to keep old source working. Unlike Q4List, I propose to add Q5ArrayList as an alias to Q5List so users can start pointing out in their code pleases where they require the list-ness of QList, before Qt 6 comes along. Likewise, Qt can provide in its API hints which QLists provide stable references and which don't. Which of those we port to QVector (probably all) and which ones we keep as QArrayList (probably none), come Qt 6, is an entirely different matter. By making QArrayList an alias in Qt 5 and QList an alias in Qt 6, we keep these types out of the ABI while maintaining SC and BC. That is, IMO, why we need QArrayList. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Wed Mar 29 14:33:19 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 29 Mar 2017 14:33:19 +0200 Subject: [Development] QList In-Reply-To: <7b738e2e-2689-ca56-9bc6-e498174429d8@kdab.com> References: <201703291327.47031.marc.mutz@kdab.com> <7b738e2e-2689-ca56-9bc6-e498174429d8@kdab.com> Message-ID: <201703291433.19708.marc.mutz@kdab.com> On Wednesday 29 March 2017 14:20:42 Giuseppe D'Angelo wrote: > Il 29/03/2017 13:27, Marc Mutz ha scritto: > > On Wednesday 29 March 2017 11:37:57 Ville Voutilainen wrote: > >> Let me take a step back. Do we need a list container that is always > >> indirect regardless of > >> the element type and uses implicit sharing? > > > > We have that: it's called QLinkedList. > > Or, fixing QVector so that QVector> becomes supported. A QVector that supports move-only type ceases to be CoW, because its copy ctor will be disabled. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From ville.voutilainen at gmail.com Wed Mar 29 14:47:03 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 29 Mar 2017 15:47:03 +0300 Subject: [Development] QList In-Reply-To: <201703291431.51173.marc.mutz@kdab.com> References: <201703291326.21608.marc.mutz@kdab.com> <201703291431.51173.marc.mutz@kdab.com> Message-ID: On 29 March 2017 at 15:31, Marc Mutz wrote: >> All this makes me wonder why we should have QArrayList at all. If it's >> slated for immediate deprecation, > > I said _I_ would immediately deprecate it. Wether we do depends on a lot of > other things, too. E.g. what will happen to our other containers. > >> we perhaps should never let it out, and just tell people to use >> QVector or QLinkedList instead of QList. > > It's part of the QList exit strategy. Q6ArrayList will be one and Q6Vector the > other implementation underlying Q6List, which then will be the template alias > that contains the std::conditional that we currently have inside QList. That sounds like we will continue to have a QArrayList. Sure, we can try to not expose it, but having a guaranteed-indirect-storate CoW list seems plenty attractive. > We can't make QLinkedList the other implementation beside QVector, since > QLinkedList does not provide an efficient index-based API (even though Qt > tried that, too: http://doc.qt.io/qt-4.8/q3valuelist.html). Like the > Q3ValueList in that link, it's a vehicle to keep old source working. Indeed, which suggests that there may be sufficient motivation for QArrayList as a separate container. From olivier at woboq.com Wed Mar 29 14:53:28 2017 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 29 Mar 2017 14:53:28 +0200 Subject: [Development] QList In-Reply-To: <20170329133311.BE17.6F0322A@gmail.com> References: <201703290937.05395.marc.mutz@kdab.com> <1754264.rmNIGM7Dej@maurice> <20170329133311.BE17.6F0322A@gmail.com> Message-ID: <1575330.JDlXlZBg3L@maurice> On Mittwoch, 29. März 2017 13:33:12 CEST Philippe wrote: > On Wed, 29 Mar 2017 10:39:42 +0200 > > Olivier Goffart wrote: > > I don't think we need QArrayList. As you said, it's not often used (only > > one known use?). and QToolBox is not even using the implicit sharing, so > > it could easily be ported so std::vector> > > When you need an index-based container, to insert and sort many big > objects, a QList like container is ideal. > Easier than std::vector> and with the benefit of cow. COW does not make much sense for a "QArrayList", as a detach would suddenly copy all the elements and break the references. (And QToolBox for example don't share its internal list) From ville.voutilainen at gmail.com Wed Mar 29 15:09:07 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 29 Mar 2017 16:09:07 +0300 Subject: [Development] QList In-Reply-To: <1575330.JDlXlZBg3L@maurice> References: <201703290937.05395.marc.mutz@kdab.com> <1754264.rmNIGM7Dej@maurice> <20170329133311.BE17.6F0322A@gmail.com> <1575330.JDlXlZBg3L@maurice> Message-ID: On 29 March 2017 at 15:53, Olivier Goffart wrote: > On Mittwoch, 29. März 2017 13:33:12 CEST Philippe wrote: >> On Wed, 29 Mar 2017 10:39:42 +0200 >> >> Olivier Goffart wrote: >> > I don't think we need QArrayList. As you said, it's not often used (only >> > one known use?). and QToolBox is not even using the implicit sharing, so >> > it could easily be ported so std::vector> >> >> When you need an index-based container, to insert and sort many big >> objects, a QList like container is ideal. >> Easier than std::vector> and with the benefit of cow. > > COW does not make much sense for a "QArrayList", as a detach would suddenly > copy all the elements and break the references. > (And QToolBox for example don't share its internal list) Ha, good point - reference stability and CoW don't seem to mix. That leaves the question whether we want guaranteed indirect storage and an indexing api. Which is something like a std::vector>. From mwoehlke.floss at gmail.com Wed Mar 29 16:41:38 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 29 Mar 2017 10:41:38 -0400 Subject: [Development] QList In-Reply-To: <201703291326.21608.marc.mutz@kdab.com> References: <201703291029.57727.marc.mutz@kdab.com> <201703291326.21608.marc.mutz@kdab.com> Message-ID: <58DBC7A2.2080105@gmail.com> On 2017-03-29 07:26, Marc Mutz wrote: > That brings us straight back to the fundamental question: Why can the C++ > world at large cope with containers that are not CoW and Qt cannot? The only > answer I have is "because Qt never tried". And that's the end of it. I have > pointed to Herb's string measurements from a decade or two ago. I have shown > that copying a std::vector up to 1K ints is faster than a QVector, when > hammered by at least two threads. 4 KiB of memory is not very much. What happens if you have larger objects (say, 100 objects with 96 bytes each)? What if you have an API that needs value semantics (keep in mind one benefit of CoW is implicit shared lifetime management) but tend to not actually modify the "copied" list? What benchmarks have been done on *real applications*? What were the results? > (I just had to review _another_ pimpl'ed class that contained > nothing but two enums) ...and what happens if at some point in the future that class needs three enums? Or some other member? What, exactly, do you find objectionable about PIMPL in "modern C++"? It can't be that it's inefficient, because performance was never a goal of PIMPL. >> so I can't pass it by value into slots. > > Why would you want to? No-one does that. People use cref, like for all large > types. Qt makes sure that a copy is taken only when needed, ie. when the slot > is in a different thread from the emitter. That is very rare, and people can > be expected to pass a shared_ptr instead in these situations. This (passing lists across thread boundaries in signals/slots) happens quite a bit in https://github.com/kitware/vivia/. Doing so is a fundamental part of the data processing architecture of at least two of the applications there. Also, explicit sharing borders on premature pessimization. If my slot needs to modify the data, I have to go out of my way to avoid making an unnecessary copy. (This argument would be more compelling if C++ had a cow_ptr.) -- Matthew From marc.mutz at kdab.com Wed Mar 29 17:28:00 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 29 Mar 2017 17:28:00 +0200 Subject: [Development] QList In-Reply-To: <58DBC7A2.2080105@gmail.com> References: <201703291029.57727.marc.mutz@kdab.com> <201703291326.21608.marc.mutz@kdab.com> <58DBC7A2.2080105@gmail.com> Message-ID: On 2017-03-29 16:41, Matthew Woehlke wrote: > On 2017-03-29 07:26, Marc Mutz wrote: >> That brings us straight back to the fundamental question: Why can the >> C++ >> world at large cope with containers that are not CoW and Qt cannot? >> The only >> answer I have is "because Qt never tried". And that's the end of it. I >> have >> pointed to Herb's string measurements from a decade or two ago. I have >> shown >> that copying a std::vector up to 1K ints is faster than a QVector, >> when >> hammered by at least two threads. > > 4 KiB of memory is not very much. What happens if you have larger > objects (say, 100 objects with 96 bytes each)? The same. QVector has a hw mutex around the ref counting. Only one core can have write access to any given cache line. So the rate with which you can update the ref count is limited by the rate a single core can update it (in memory), divided by a factor that accounts for cache-line ping-pong. It can be as high as 2. Deep-copying does not write to the source object, and any number of cores can share read access for a given cache line, each with its own copy, so deep-copying scales linearly with the number of cores. Therefore, for any given element size and count there exists a thread count where deep-copying becomes faster than CoW. Yes, even for 1K objects of 1K size each. > What if you have an API that needs value semantics (keep in mind one > benefit of CoW is implicit shared lifetime management) but tend to not > actually modify the "copied" list? std::vector has value semantics. OTOH, QVector's CoW leaks its reference semantics, e.g. if you take an iterator into a container, copy the container, then write to the iterator, you wrote to both copies. > What benchmarks have been done on *real applications*? What were the > results? What benchmarks have *you* done? The world outside Qt is happily working with CoWless containers. It's proponents of CoW who need to show that CoW is a global optimisation and not just for copying of certain element counts and sizes. >> (I just had to review _another_ pimpl'ed class that contained >> nothing but two enums) > > ...and what happens if at some point in the future that class needs > three enums? Or some other member? When you start with the class, you pack the two values into a bit-field and add reserved space to a certain size. 4 or 8 bytes. When you run out, you make a V2 and add an overload taking V2. That is perfectly ok, since old code can't use new API. This doesn't mean you should never use pimpl. But it means you shouldn't use it just because you can. > What, exactly, do you find objectionable about PIMPL in "modern C++"? > It > can't be that it's inefficient, because performance was never a goal of > PIMPL. Performance is always a goal in C++. Even in Qt. Otherwise QRect would be pimpled, too. >>> so I can't pass it by value into slots. >> >> Why would you want to? No-one does that. People use cref, like for all >> large >> types. Qt makes sure that a copy is taken only when needed, ie. when >> the slot >> is in a different thread from the emitter. That is very rare, and >> people can >> be expected to pass a shared_ptr instead in these situations. > > This (passing lists across thread boundaries in signals/slots) happens > quite a bit in https://github.com/kitware/vivia/. Doing so is a > fundamental part of the data processing architecture of at least two of > the applications there. Qt supports thousands of applications. We shouldn't optimize for corner-cases. > Also, explicit sharing borders on premature pessimization. If my slot > needs to modify the data, I have to go out of my way to avoid making an > unnecessary copy. (This argument would be more compelling if C++ had a > cow_ptr.) You got that the wrong way around. Thanks, Marc From thiago.macieira at intel.com Wed Mar 29 17:44:35 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 29 Mar 2017 08:44:35 -0700 Subject: [Development] Wishes for C++ standard or compilers In-Reply-To: References: <14194925.OZWiO3H5W7@tjmaciei-mobl1> <201703291149.33049.marc.mutz@kdab.com> Message-ID: <1632952.ZVxWKhJFMp@tjmaciei-mobl1> On quarta-feira, 29 de março de 2017 02:53:16 PDT Ville Voutilainen wrote: > The hard number we still need is this: > 1) how much of a performance difference does a destructive move make QVector is all you need to see that. Without destructive moves: 1) allocate new block 2) move each element (constructor is noexcept, good) -> could be a memcpy + memset, but isn't... 3) destroy each element (refcount is checked every time!) 4) deallocate the old block With destructive moves: 1) allocate new block 2) destructive-move every element (a memcpy, whether explicit or not) 3) deallocate the old block With trivial destructive moves: 1) realloc Do we need to actually benchmark this? > The softer numbers we need are these: > a) how many types benefit from it $ git sgrep -E 'Q_DECLARE_TYPEINFO.*Q_(MOVABLE|PRIMITIVE)' | wc -l 442 > b) how often are those types used QString and QByteArray are among them, so extremely often. > c) what are the practical performance improvements, assuming that the > hard number (1) gave us a benchmark number. See above. > If "you don't need hard numbers", be prepared to live with a C++ that > doesn't have > a destructive move. Assuming that everyone in the committee finds its > motivation obviously sound is a losing strategy, as is assuming that many > people in the committee > are aware of how destructive move helps implicit-sharing containers. Ok, so I guess we can easily benchmark this by making the Qt containers forget about the movable property, then benchmark the load time of a large application like Qt Creator. Unfortunately, this means recompiling everything, since containers are inlined everywhere. It's easy (a two-line change in qtypeinfo.h), but takes times. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From edward.welbourne at qt.io Wed Mar 29 18:03:05 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 29 Mar 2017 16:03:05 +0000 Subject: [Development] Who's responsible for 3rdparty these days (QTBUG-59586)? In-Reply-To: References: <1923287.X8lTtAKxnU@tjmaciei-mobl1>, Message-ID: On 19 March 2017 at 20:01, Thiago Macieira > wrote: >> The rules are that only Qt Company people can import 3rdparty code, so I know >> I am not responsible. >> >> Who do I assign the bug to? >> https://bugreports.qt.io/browse/QTBUG-59586 QUIP 4 (see below) should perhaps address that ... Liang Qi (29 March 2017 14:03) > For QTBUG-59586, I have https://codereview.qt-project.org/189977 and > https://github.com/liangqi/zlib/tree/qt . > > Please give some feedback. We should find a home for our "authoritative" version on systems we control (e.g. gerrit), rather than an individual developer's account on a third-party web-site. We should probably also have - somewhere - an "upstream mirror" space, where we have (at least bare) repos for all upstream projects we can (using git's ways of pulling from cvs, svn, &c.) from which we update our authoritative versions (preferably reasonably frequently). Once such a mirror is set up, it's easy for some cron jobs to keep it up to date - and generate grumble mails to someone suitable when the upstreams move, change version control system or do other disruptive things that we'll need to keep track of if we're ever to update to a later version. Whether that upstream space is just a branch name-space within the authoritative repos or a separate directory of (perhaps bare) repos is an implementation detail I leave to whoever might set it up. It should be visible to Maintainers generally, if only so that we can discover how behind our "live" version has fallen. > And I still have a general question: > > I have seen this new git submodule way in qtlocation, like > http://code.qt.io/cgit/qt/qtlocation-mapboxgl.git/ . In connection with that, I notice that qtlocation/src/3rdparty/mapbox-gl-native/src/3rd_party/ (presumably the 3rdparty code of our 3rdparty code is at least 4th-party for us) has several sub-directories, each with a .gitmodules that points at https://github.com/mapbox/mason (sometimes with .git suffix, sometimes without). The duplication makes me twitchy (as does the variation in url), but maybe it's needed ... and it's in third-party components, so maybe this is just derived from their upstreams. > So should we do a mirror in code.qt.io first and > then add this in the modules? And there is common procedure for this > purpose? for example, patches and qt_attribution.json file if upstream > doesn't have it. We could definitely benefit from some common process for maintaining our mirrors of upstreams. The qt_attribution.json should be present in our source tree; see QUIP 4: * https://codereview.qt-project.org/177201 * https://quips-qt-io.herokuapp.com/quip-0004.html Eddy. From thiago.macieira at intel.com Wed Mar 29 18:10:01 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 29 Mar 2017 09:10:01 -0700 Subject: [Development] Wishes for C++ standard or compilers In-Reply-To: <1632952.ZVxWKhJFMp@tjmaciei-mobl1> References: <14194925.OZWiO3H5W7@tjmaciei-mobl1> <1632952.ZVxWKhJFMp@tjmaciei-mobl1> Message-ID: <49707735.uocPeCQTp8@tjmaciei-mobl1> On quarta-feira, 29 de março de 2017 08:44:35 PDT Thiago Macieira wrote: > Ok, so I guess we can easily benchmark this by making the Qt containers > forget about the movable property, then benchmark the load time of a large > application like Qt Creator. Unfortunately, this means recompiling > everything, since containers are inlined everywhere. It's easy (a two-line > change in qtypeinfo.h), but takes times. Ok, not so easy because QVector does not implement detaching by moves. Here's what it looks like for me: const size_t newSize = size() + std::distance(i1, i2); const bool isTooSmall = newSize > d->allocatedCapacity(); const bool isOverlapping = d->begin() <= i1 && i2 <= d->end(); if (isTooSmall || d->needsDetach() || Q_UNLIKELY(isOverlapping)) { typename Data::ArrayOptions flags = d->detachFlags(); if (isTooSmall) flags |= Data::GrowsForward; DataPointer detached(Data::allocate(d->detachCapacity(newSize), flags)); detached->copyAppend(constBegin(), constEnd()); detached->copyAppend(i1, i2); d.swap(detached); } else { // we're detached and we can just move data around d->copyAppend(i1, i2); } I'd need to insert a third branch, splitting the isTooSmall case from the d->needsDetach() one. Then we could do moves. This needs to be implemented in the other containers too before we can benchmark. Q1: Where's this code which you've pasted? It's QGenericArray https://gitlab.com/thiagomacieira/qtbase/blob/master/src/corelib/tools/ qgenericarray.h#L559 Q2: Where's the handling of movable types? Hidden behind QArrayDataPointer, see your qarraydataops.h for copyAppend. This is actually exception-safe. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Wed Mar 29 18:57:44 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 29 Mar 2017 12:57:44 -0400 Subject: [Development] QList In-Reply-To: References: <201703291029.57727.marc.mutz@kdab.com> <201703291326.21608.marc.mutz@kdab.com> <58DBC7A2.2080105@gmail.com> Message-ID: <58DBE788.50609@gmail.com> On 2017-03-29 11:28, Marc Mutz wrote: > Deep-copying does not write to the source object, and any number of > cores can share read access for a given cache line, each with its own > copy, so deep-copying scales linearly with the number of cores. Deep copying is vectorized? Really? > On 2017-03-29 16:41, Matthew Woehlke wrote: >> On 2017-03-29 07:26, Marc Mutz wrote: >>> (I just had to review _another_ pimpl'ed class that contained >>> nothing but two enums) >> >> ...and what happens if at some point in the future that class needs >> three enums? Or some other member? > > When you start with the class, you pack the two values into a bit-field > and add reserved space to a certain size. 4 or 8 bytes. When you run > out, you make a V2 and add an overload taking V2. Um... I'm not even going to comment... > This doesn't mean you should never use pimpl. But it means you > shouldn't use it just because you can. Well, sure, but that's not how your original comment came across. >> What, exactly, do you find objectionable about PIMPL in "modern C++"? It >> can't be that it's inefficient, because performance was never a goal of >> PIMPL. > > Performance is always a goal in C++. Even in Qt. Otherwise QRect would > be pimpled, too. Performance is not a primary goal of PIMPL. That doesn't mean you should *never* use it, or that the goals it does achieve are worthless. I think the main reason some many people disagree with you on CoW and related subjects is because you put performance above all else, including correctness and ease of use. I know you're going to reply "but if the library doesn't do that, users that *do* value performance are SOL". That argument cuts both ways, however; if the library doesn't provide ease-of-correct-use, users that prefer *that* are equally SOL. -- Matthew From mwoehlke.floss at gmail.com Wed Mar 29 18:57:44 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 29 Mar 2017 12:57:44 -0400 Subject: [Development] QList In-Reply-To: References: <201703291029.57727.marc.mutz@kdab.com> <201703291326.21608.marc.mutz@kdab.com> <58DBC7A2.2080105@gmail.com> Message-ID: <58DBE788.50609@gmail.com> On 2017-03-29 11:28, Marc Mutz wrote: > Deep-copying does not write to the source object, and any number of > cores can share read access for a given cache line, each with its own > copy, so deep-copying scales linearly with the number of cores. Deep copying is vectorized? Really? > On 2017-03-29 16:41, Matthew Woehlke wrote: >> On 2017-03-29 07:26, Marc Mutz wrote: >>> (I just had to review _another_ pimpl'ed class that contained >>> nothing but two enums) >> >> ...and what happens if at some point in the future that class needs >> three enums? Or some other member? > > When you start with the class, you pack the two values into a bit-field > and add reserved space to a certain size. 4 or 8 bytes. When you run > out, you make a V2 and add an overload taking V2. Um... I'm not even going to comment... > This doesn't mean you should never use pimpl. But it means you > shouldn't use it just because you can. Well, sure, but that's not how your original comment came across. >> What, exactly, do you find objectionable about PIMPL in "modern C++"? It >> can't be that it's inefficient, because performance was never a goal of >> PIMPL. > > Performance is always a goal in C++. Even in Qt. Otherwise QRect would > be pimpled, too. Performance is not a primary goal of PIMPL. That doesn't mean you should *never* use it, or that the goals it does achieve are worthless. I think the main reason some many people disagree with you on CoW and related subjects is because you put performance above all else, including correctness and ease of use. I know you're going to reply "but if the library doesn't do that, users that *do* value performance are SOL". That argument cuts both ways, however; if the library doesn't provide ease-of-correct-use, users that prefer *that* are equally SOL. -- Matthew From olivier at woboq.com Wed Mar 29 19:17:49 2017 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 29 Mar 2017 19:17:49 +0200 Subject: [Development] Wishes for C++ standard or compilers In-Reply-To: References: <14194925.OZWiO3H5W7@tjmaciei-mobl1> <201703291149.33049.marc.mutz@kdab.com> Message-ID: <2726443.oBOj2uWz6H@maurice> On Mittwoch, 29. März 2017 11:53:16 CEST Ville Voutilainen wrote: > On 29 March 2017 at 12:49, Marc Mutz wrote: > > This is probably one of the most important things. Ville asked on std- > > proposals to show hard numbers. You don't need hard numbers. You just need > > to superficially look at QVector. The compiler generally cannot > > proove that the call to QArrayData::deallocate() can be dropped from the > > QString dtor. It will always emit the atomic lock;sub and the call to > > deallocate(), even though the move ctor is inline and sets the d-pointer > > to sharedNull(). I have tried many things over the past year or so, incl. > > Q_ASSUME(!ref == -1) in sharedNull() and explicitly checking for that > > same condition in the QString dtor. It just doesn't help. > > > > This is an example of the WTF missed-optimisation that Chandler presented > > at MeetingC++ 2016: https://www.youtube.com/watch?v=s4wnuiCwTGU > > > > Only difference: we need it for thousands of items, not just four. > > The hard number we still need is this: > 1) how much of a performance difference does a destructive move make > > The softer numbers we need are these: > a) how many types benefit from it > b) how often are those types used > c) what are the practical performance improvements, assuming that the > hard number (1) > gave us a benchmark number. > > If "you don't need hard numbers", be prepared to live with a C++ that > doesn't have > a destructive move. Assuming that everyone in the committee finds its > motivation obviously sound is a losing strategy, as is assuming that many > people in the committee > are aware of how destructive move helps implicit-sharing containers. A destructive move has actually already been proposed: N4158 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4158.pdf This was from 2014 and proposed std::uninitialized_destructive_move Later, in 2015 there was N4393 that references it http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4393.pdf But I don't know if anything went further than that. Can we live without it in Qt? I would like to point out the the optimization we do currently with QVector and Q_DECLARE_TYPEINFO(Q_MOVABLE) is technically an undefined behavior, I think. (I believe a sanitizer using shadow memory to check the lifetime of objects would catch this. It's not allowed to use memcpy on types that are not trivially copyable) So Qt currently invoke quite a lot of UB. And having a standard way to do that would be great. -- Olivier From marc.mutz at kdab.com Wed Mar 29 20:11:58 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 29 Mar 2017 20:11:58 +0200 Subject: [Development] QList In-Reply-To: <58DBE788.50609@gmail.com> References: <201703291029.57727.marc.mutz@kdab.com> <201703291326.21608.marc.mutz@kdab.com> <58DBC7A2.2080105@gmail.com> <58DBE788.50609@gmail.com> Message-ID: On 2017-03-29 18:57, Matthew Woehlke wrote: > On 2017-03-29 11:28, Marc Mutz wrote: >> Deep-copying does not write to the source object, and any number of >> cores can share read access for a given cache line, each with its own >> copy, so deep-copying scales linearly with the number of cores. > > Deep copying is vectorized? Really? No. Maybe you should read what you're replying to first. The benchmark was about concurrent copying from a const vector. >> On 2017-03-29 16:41, Matthew Woehlke wrote: >>> On 2017-03-29 07:26, Marc Mutz wrote: >>>> (I just had to review _another_ pimpl'ed class that contained >>>> nothing but two enums) >>> >>> ...and what happens if at some point in the future that class needs >>> three enums? Or some other member? >> >> When you start with the class, you pack the two values into a >> bit-field >> and add reserved space to a certain size. 4 or 8 bytes. When you run >> out, you make a V2 and add an overload taking V2. > > Um... I'm not even going to comment... Keyword: inline namespaces. This is the C++ mechanism for API versioning. It allows to make that totally transparent. Why you find that so odd as to be lacking for words is beyond me. >> This doesn't mean you should never use pimpl. But it means you >> shouldn't use it just because you can. > > Well, sure, but that's not how your original comment came across. [...] > Performance is not a primary goal of PIMPL. That doesn't mean you > should > *never* use it, or that the goals it does achieve are worthless. I have given pretty concrete suggestions in the past on when not to use it: if your class has no user-settable properties, don't pimpl it. If your class contains only two enums, even if you expect more later, don't pimpl it. If you construe that as saying "never use pimpl", from the author of the Pimp my Pimpl series of articles, then that's your problem. > I think the main reason some many people disagree with you on CoW and > related subjects is because you put performance above all else, > including correctness and ease of use. Interesting. My criticism of CoW is about correctness _and_ performance. I have given the iterator-into-copied-container example several times now. Correctness issue. I have also said that what I hate most about QList is how the memory layout depends on intricate details like the machine word size. Correctness issue. > I know you're going to reply "but if the library doesn't do that, users > that *do* value performance are SOL". That argument cuts both ways, > however; if the library doesn't provide ease-of-correct-use, users that > prefer *that* are equally SOL. Given that QVector provides the same as std::vector, except exception safety, correct value semantics (iterator-into-copy), accurate complexity guarantees, move-only payload support, I would really, really like to know why QVector is easier to use? Because it has indexOf()? Seriously, now? Thanks, Marc From mwoehlke.floss at gmail.com Wed Mar 29 20:27:16 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 29 Mar 2017 14:27:16 -0400 Subject: [Development] QList In-Reply-To: References: <201703291029.57727.marc.mutz@kdab.com> <201703291326.21608.marc.mutz@kdab.com> <58DBC7A2.2080105@gmail.com> <58DBE788.50609@gmail.com> Message-ID: <58DBFC84.2000706@gmail.com> On 2017-03-29 14:11, Marc Mutz wrote: > On 2017-03-29 18:57, Matthew Woehlke wrote: >> I think the main reason some many people disagree with you on CoW and >> related subjects is because you put performance above all else, >> including correctness and ease of use. > > Interesting. My criticism of CoW is about correctness _and_ performance. > I have given the iterator-into-copied-container example several times > now. Correctness issue. I suspect that's not very common, or more people would complain about it. It's also possible to implement CoW in a way that doesn't have this issue. (I've done it, but I believe it would be impractical or compatibility-breaking to retrofit into Qt containers. Also, it requires some extra bookkeeping that probably doesn't improve performance.) > I have also said that what I hate most about > QList is how the memory layout depends on intricate details like the > machine word size. Correctness issue. Granted, but that isn't related to CoW. I have seen much less disagreement on being consistent whether a container stores the items indirectly. -- Matthew From mwoehlke.floss at gmail.com Wed Mar 29 20:27:16 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 29 Mar 2017 14:27:16 -0400 Subject: [Development] QList In-Reply-To: References: <201703291029.57727.marc.mutz@kdab.com> <201703291326.21608.marc.mutz@kdab.com> <58DBC7A2.2080105@gmail.com> <58DBE788.50609@gmail.com> Message-ID: <58DBFC84.2000706@gmail.com> On 2017-03-29 14:11, Marc Mutz wrote: > On 2017-03-29 18:57, Matthew Woehlke wrote: >> I think the main reason some many people disagree with you on CoW and >> related subjects is because you put performance above all else, >> including correctness and ease of use. > > Interesting. My criticism of CoW is about correctness _and_ performance. > I have given the iterator-into-copied-container example several times > now. Correctness issue. I suspect that's not very common, or more people would complain about it. It's also possible to implement CoW in a way that doesn't have this issue. (I've done it, but I believe it would be impractical or compatibility-breaking to retrofit into Qt containers. Also, it requires some extra bookkeeping that probably doesn't improve performance.) > I have also said that what I hate most about > QList is how the memory layout depends on intricate details like the > machine word size. Correctness issue. Granted, but that isn't related to CoW. I have seen much less disagreement on being consistent whether a container stores the items indirectly. -- Matthew From thiago.macieira at intel.com Wed Mar 29 22:12:30 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 29 Mar 2017 13:12:30 -0700 Subject: [Development] QList In-Reply-To: References: <58DBE788.50609@gmail.com> Message-ID: <2125915.ATCG3VibXO@tjmaciei-mobl1> On quarta-feira, 29 de março de 2017 11:11:58 PDT Marc Mutz wrote: > Keyword: inline namespaces. This is the C++ mechanism for API > versioning. It allows to make that totally transparent. Why you find > that so odd as to be lacking for words is beyond me. Inline namespaces do not solve the binary compatibility problem. They should not be used in Qt API for versioning. Instead, do what you said before: create a V2 class. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philwave at gmail.com Wed Mar 29 23:17:31 2017 From: philwave at gmail.com (Philippe) Date: Wed, 29 Mar 2017 23:17:31 +0200 Subject: [Development] QList In-Reply-To: References: <58DBE788.50609@gmail.com> Message-ID: <20170329231730.D1F6.6F0322A@gmail.com> > I would really, really like to know why QVector is easier to use? Following common methods are immediate. With std::vector, you need to add boilerplate code to achieve the same. QVector::insert QVector::remove QVector::value(int i, const T &defaultValue) QVector::move QVector::contains QVector::operator+=(const QVector &other) Not to mention the many other convenient QVector methods. And being able to use a QVector with O(1) by-value assigment, thanks to COW, make it easy to use QVectors "as primitive types", with no reasonning effort. Philippe From annulen at yandex.ru Thu Mar 30 00:33:51 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 30 Mar 2017 01:33:51 +0300 Subject: [Development] QList In-Reply-To: <20170329231730.D1F6.6F0322A@gmail.com> References: <58DBE788.50609@gmail.com> <20170329231730.D1F6.6F0322A@gmail.com> Message-ID: <549911490826831@web19j.yandex.ru> 30.03.2017, 00:17, "Philippe" : >>  I would really, really like to know why QVector is easier to use? > > Following common methods are immediate. With std::vector, you need to > add boilerplate code to achieve the same. > > QVector::insert > QVector::remove > QVector::value(int i, const T &defaultValue) > QVector::move > QVector::contains > QVector::operator+=(const QVector &other) > > Not to mention the many other convenient QVector methods. > > And being able to use a QVector with O(1) by-value assigment, thanks to > COW, make it easy to use QVectors "as primitive types", with no > reasonning effort. With move semantics you can achieve this without CoW in a more explicit way > > Philippe > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Thu Mar 30 00:59:29 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 29 Mar 2017 15:59:29 -0700 Subject: [Development] Wishes for C++ standard or compilers In-Reply-To: <1632952.ZVxWKhJFMp@tjmaciei-mobl1> References: <14194925.OZWiO3H5W7@tjmaciei-mobl1> <1632952.ZVxWKhJFMp@tjmaciei-mobl1> Message-ID: <3107279.V8beLjr0kR@tjmaciei-mobl1> On quarta-feira, 29 de março de 2017 08:44:35 PDT Thiago Macieira wrote: > Without destructive moves: > 1) allocate new block > 2) move each element (constructor is noexcept, good) > -> could be a memcpy + memset, but isn't... > 3) destroy each element (refcount is checked every time!) > 4) deallocate the old block > > With destructive moves: > 1) allocate new block > 2) destructive-move every element (a memcpy, whether explicit or not) > 3) deallocate the old block > > With trivial destructive moves: > 1) realloc > > Do we need to actually benchmark this? Ok, so I have. This is of course a microbenchmark. Source code: http://paste.opensuse.org/83426813 [Requires my branch's QArrayData] Without further ado, results. Analysis and conclusions below. GCC 6.3:,CPU cycles,% of move, copyTrivial,"7.015.001,04688",105%, moveTrivial,"6.653.361,60938",100%, memcpyTrivial,"5.556.582,67969",84%, reallocTrivial,"3.209.727,01953",48%, copyComplex,"50.938.402,71875",99%, moveComplex,"51.306.523,56250",100%, memcpyComplex,"40.689.058,50000",79%, reallocComplex,"13.450.587,92188",26%, ,,, Clang trunk:,,, copyTrivial,"6.366.532,53906",101%, moveTrivial,"6.284.109,14063",100%, memcpyTrivial,"6.410.652,50000",102%, reallocTrivial,"3.926.226,85547",62%, copyComplex,"44.778.841,93750",84%, moveComplex,"53.097.208,06250",100%, memcpyComplex,"38.966.088,87500",73%, reallocComplex,"12.701.627,09375",24%, ,,, ICC 17:,,, copyTrivial,"7.656.487,46094",100%, moveTrivial,"7.688.472,17969",100%, memcpyTrivial,"8.346.315,19531",109%, reallocTrivial,"4.885.068,30859",64%, copyComplex,"68.326.384,37500",91%, moveComplex,"75.145.256,50000",100%, memcpyComplex,"52.546.942,75000",70%, reallocComplex,"29.427.426,37500",39%, Analysis: 1) I've valground the application and it leaks no memory 2) the application was compiled with exceptions disabled, as we're not testing the exceptional code paths. This also simulates a complex type that has a noexcept move constructor. 3) because this is using QArrayData allocation with GrowsForward, the reallocation strategy does not happen on every execution. In fact, to append one million items, the allocate() function is called only 59 times. 4) the benchmarks only the appending into the vector. The freeing of the vector's elements at the end is not included. 5) there are four times two tests: copy + destroy original move + destroy original memcpy pure realloc run each for a trivial type (int) a complex but relocatable type (QString) 6) the test is skewed towards realloc because there's no other memory allocation, so realloc() is free to resize the memory block in-place, as it sees fit. Tough luck for the other tests. 7) the copy and move operations for the trivial type are, as expected, within the noise of each other. The 5% of the spike for GCC does not appear in all runs (the first test suffers a little due to warming up and the need to obtain memory from the OS). 8) the difference between copy/move and memcpy for the trivial type depend on the compiler. I compiled using -O2, which means GCC did not use its vectoriser, but Clang did (-march=native, so they used AVX2). Meanwhile, all three called the libc memcpy function in the memcpy version, which has vectorisation (in ICC's case, it called __intel_avx_rep_memcpy). Conclusions: A) for trivial types, the relocation provides negligible, if any, improvement, as the operation is already there. But as shown, not all compilers are as smart and may miss optimisation opportunities by its absence. The more information the compiler has, the better it can generate code. B) for non-trivial types, the relocation provides 25% or more performance improvement (1 / 80% = 125%). That's probably because QString's destructor is actually non-negligible, as it needs to check if the data block it points to needs to be freed. C) the realloc strategy is clearly the winner here, achieving up to 316% improvement over today's state-of-the-art. As stated in the analysis, this happens with only 59 allocations out of 1 million elements appended. Now, since nothing else was allocated in this benchmark, realloc() most likely did not have to perform memcpy, so these numbers are not representative of all applications, but they are possible and can even be surpassed with dedicated arena allocators. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Thu Mar 30 07:20:11 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 30 Mar 2017 07:20:11 +0200 Subject: [Development] QList In-Reply-To: <2125915.ATCG3VibXO@tjmaciei-mobl1> References: <2125915.ATCG3VibXO@tjmaciei-mobl1> Message-ID: <201703300720.12134.marc.mutz@kdab.com> On Wednesday 29 March 2017 22:12:30 Thiago Macieira wrote: > On quarta-feira, 29 de março de 2017 11:11:58 PDT Marc Mutz wrote: > > Keyword: inline namespaces. This is the C++ mechanism for API > > versioning. It allows to make that totally transparent. Why you find > > that so odd as to be lacking for words is beyond me. > > Inline namespaces do not solve the binary compatibility problem. They > should not be used in Qt API for versioning. > > Instead, do what you said before: create a V2 class. Since the two are totally identical, except that inline namespaces are transparent to the user, please explain what leads you to this distinction. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From olivier at woboq.com Thu Mar 30 08:18:52 2017 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 30 Mar 2017 08:18:52 +0200 Subject: [Development] QList In-Reply-To: <201703300720.12134.marc.mutz@kdab.com> References: <2125915.ATCG3VibXO@tjmaciei-mobl1> <201703300720.12134.marc.mutz@kdab.com> Message-ID: <2150595.QtpvzlfFUP@maurice> On Donnerstag, 30. März 2017 07:20:11 CEST Marc Mutz wrote: > On Wednesday 29 March 2017 22:12:30 Thiago Macieira wrote: > > On quarta-feira, 29 de março de 2017 11:11:58 PDT Marc Mutz wrote: > > > Keyword: inline namespaces. This is the C++ mechanism for API > > > versioning. It allows to make that totally transparent. Why you find > > > that so odd as to be lacking for words is beyond me. > > > > Inline namespaces do not solve the binary compatibility problem. They > > should not be used in Qt API for versioning. > > > > Instead, do what you said before: create a V2 class. > > Since the two are totally identical, except that inline namespaces are > transparent to the user, please explain what leads you to this distinction. Library 1: inline namespace v1 { class Foo {}; } Library 2: LIBRARY2_EXPORT void registerPlugin(Foo*); -> symbol gets mangled as "registerPlugin(v1::Foo*)" Application: registerPlugin(new Foo); -> calls exported symbol "registerPlugin(v1::Foo*)" When Library 1 puts Foo in the v2 inline namespace, recompile Library2 and the exported symbol becomes "registerPlugin(v2::Foo*)". If Application is not recompiled, it will not work as the old symbol is no longer found. So what that means is that technically, Library 1 did not break its binary compatibility. But any library using Library 1 in their ABI is breaking compatibility when they get recompiled. GCC's ABI tag extension have the exact same problem. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From marc.mutz at kdab.com Thu Mar 30 08:32:24 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 30 Mar 2017 08:32:24 +0200 Subject: [Development] QList In-Reply-To: <2150595.QtpvzlfFUP@maurice> References: <201703300720.12134.marc.mutz@kdab.com> <2150595.QtpvzlfFUP@maurice> Message-ID: <201703300832.25437.marc.mutz@kdab.com> On Thursday 30 March 2017 08:18:52 Olivier Goffart wrote: > On Donnerstag, 30. März 2017 07:20:11 CEST Marc Mutz wrote: > > On Wednesday 29 March 2017 22:12:30 Thiago Macieira wrote: > > > On quarta-feira, 29 de março de 2017 11:11:58 PDT Marc Mutz wrote: > > > > Keyword: inline namespaces. This is the C++ mechanism for API > > > > versioning. It allows to make that totally transparent. Why you find > > > > that so odd as to be lacking for words is beyond me. > > > > > > Inline namespaces do not solve the binary compatibility problem. They > > > should not be used in Qt API for versioning. > > > > > > Instead, do what you said before: create a V2 class. > > > > Since the two are totally identical, except that inline namespaces are > > transparent to the user, please explain what leads you to this > > distinction. > > Library 1: > > inline namespace v1 { class Foo {}; } > > Library 2: > > LIBRARY2_EXPORT void registerPlugin(Foo*); > -> symbol gets mangled as "registerPlugin(v1::Foo*)" > > Application: > > registerPlugin(new Foo); > -> calls exported symbol "registerPlugin(v1::Foo*)" > > > When Library 1 puts Foo in the v2 inline namespace, recompile Library2 and > the exported symbol becomes "registerPlugin(v2::Foo*)". If Application is > not recompiled, it will not work as the old symbol is no longer found. Well, of couse. That's like removing the QFoo overload when you add QFooV2. Don't do that. You need to keep the v1::Foo definition as well as the v1::Foo overload, just as you need to keep the QFoo definition and the QFoo overload, when you add v2. > So what that means is that technically, Library 1 did not break its binary > compatibility. But any library using Library 1 in their ABI is breaking > compatibility when they get recompiled. > > GCC's ABI tag extension have the exact same problem. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From olivier at woboq.com Thu Mar 30 08:41:51 2017 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 30 Mar 2017 08:41:51 +0200 Subject: [Development] QList In-Reply-To: <201703300832.25437.marc.mutz@kdab.com> References: <2150595.QtpvzlfFUP@maurice> <201703300832.25437.marc.mutz@kdab.com> Message-ID: <9516701.cu2aKLv5Fy@maurice> On Donnerstag, 30. März 2017 08:32:24 CEST Marc Mutz wrote: > On Thursday 30 March 2017 08:18:52 Olivier Goffart wrote: > > On Donnerstag, 30. März 2017 07:20:11 CEST Marc Mutz wrote: > > > On Wednesday 29 March 2017 22:12:30 Thiago Macieira wrote: > > > > On quarta-feira, 29 de março de 2017 11:11:58 PDT Marc Mutz wrote: > > > > > Keyword: inline namespaces. This is the C++ mechanism for API > > > > > versioning. It allows to make that totally transparent. Why you find > > > > > that so odd as to be lacking for words is beyond me. > > > > > > > > Inline namespaces do not solve the binary compatibility problem. They > > > > should not be used in Qt API for versioning. > > > > > > > > Instead, do what you said before: create a V2 class. > > > > > > Since the two are totally identical, except that inline namespaces are > > > transparent to the user, please explain what leads you to this > > > distinction. > > > > Library 1: > > inline namespace v1 { class Foo {}; } > > > > Library 2: > > LIBRARY2_EXPORT void registerPlugin(Foo*); > > -> symbol gets mangled as "registerPlugin(v1::Foo*)" > > > > Application: > > registerPlugin(new Foo); > > -> calls exported symbol "registerPlugin(v1::Foo*)" > > > > When Library 1 puts Foo in the v2 inline namespace, recompile Library2 > > and > > the exported symbol becomes "registerPlugin(v2::Foo*)". If Application is > > not recompiled, it will not work as the old symbol is no longer found. > > Well, of couse. That's like removing the QFoo overload when you add QFooV2. > Don't do that. You need to keep the v1::Foo definition as well as the > v1::Foo overload, just as you need to keep the QFoo definition and the QFoo > overload, when you add v2. What I meant is that Library 1 becomes, in its next version namespace v1 { class Foo{}; } inline namespace v2 { class Foo{}; } It keeps v1::Foo, but puts v2::Foo in the inline namespace. If you don't use "inline namespace v2", that means users needs to explicitly use v2::Foo to use the new features. So it is no longer "transparent to the user" Personally I prefer having a pimpl so I can just add or change members. (Note that if the class is at least sizeof(void*) and that none of its member are accessed in inline methods or ctors/dtor, we can add a pimpl later, when we need it.) > > So what that means is that technically, Library 1 did not break its binary > > compatibility. But any library using Library 1 in their ABI is breaking > > compatibility when they get recompiled. > > > > GCC's ABI tag extension have the exact same problem. From marc.mutz at kdab.com Thu Mar 30 11:08:45 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 30 Mar 2017 11:08:45 +0200 Subject: [Development] inline namespaces as a versioning tool (was: Re: QList) In-Reply-To: <9516701.cu2aKLv5Fy@maurice> References: <201703300832.25437.marc.mutz@kdab.com> <9516701.cu2aKLv5Fy@maurice> Message-ID: <201703301108.46468.marc.mutz@kdab.com> On Thursday 30 March 2017 08:41:51 Olivier Goffart wrote: > On Donnerstag, 30. März 2017 08:32:24 CEST Marc Mutz wrote: > > On Thursday 30 March 2017 08:18:52 Olivier Goffart wrote: > > > On Donnerstag, 30. März 2017 07:20:11 CEST Marc Mutz wrote: > > > > On Wednesday 29 March 2017 22:12:30 Thiago Macieira wrote: > > > > > On quarta-feira, 29 de março de 2017 11:11:58 PDT Marc Mutz wrote: > > > > > > Keyword: inline namespaces. This is the C++ mechanism for API > > > > > > versioning. It allows to make that totally transparent. Why you > > > > > > find that so odd as to be lacking for words is beyond me. > > > > > > > > > > Inline namespaces do not solve the binary compatibility problem. > > > > > They should not be used in Qt API for versioning. > > > > > > > > > > Instead, do what you said before: create a V2 class. > > > > > > > > Since the two are totally identical, except that inline namespaces > > > > are transparent to the user, please explain what leads you to this > > > > distinction. > > > > > > Library 1: > > > inline namespace v1 { class Foo {}; } > > > > > > Library 2: > > > LIBRARY2_EXPORT void registerPlugin(Foo*); > > > > > > -> symbol gets mangled as "registerPlugin(v1::Foo*)" > > > > > > Application: > > > registerPlugin(new Foo); > > > > > > -> calls exported symbol "registerPlugin(v1::Foo*)" > > > > > > When Library 1 puts Foo in the v2 inline namespace, recompile Library2 > > > and > > > the exported symbol becomes "registerPlugin(v2::Foo*)". If Application > > > is not recompiled, it will not work as the old symbol is no longer > > > found. > > > > Well, of couse. That's like removing the QFoo overload when you add > > QFooV2. Don't do that. You need to keep the v1::Foo definition as well > > as the v1::Foo overload, just as you need to keep the QFoo definition > > and the QFoo overload, when you add v2. > > What I meant is that Library 1 becomes, in its next version > > namespace v1 { class Foo{}; } > inline namespace v2 { class Foo{}; } > > It keeps v1::Foo, but puts v2::Foo in the inline namespace. > > If you don't use "inline namespace v2", that means users needs to > explicitly use v2::Foo to use the new features. So it is no longer > "transparent to the user" Ok, no. library V1: inline // this inline is optional for V1 - users with compilers without // support for them need to write v1:: explicitly, or it can be // reasonably emulated with a ... namespace v1 { class Foo{ int i, }; } // ... using v1::Foo, here LIB_EXPORT void useFoo(Foo); // actually v1::Foo user V1: useFoo(Foo{}); // actually v1::Foo library V2: namespace v1 { class Foo{ int i; } } // from V1 of library inline namespace v2 { class Foo{ v1::Foo f; double d; } // adds a double member, // reuses v1::Foo LIB_EXPORT void useFoo(v1::Foo); // from V1 of library LIB_EXPORT void useFoo(Foo); // actually v2::Foo user V2 @ library V2: useFoo(Foo{}); // actually v2::Foo user V1 @ library V2: (compiled and continuing to run as) useFoo(v1::Foo{}); -> totally transparent, BC and SC Where's my mistake? > Personally I prefer having a pimpl so I can just add or change members. > > (Note that if the class is at least sizeof(void*) and that none of its > member are accessed in inline methods or ctors/dtor, we can add a pimpl > later, when we need it.) The point is to have thin abstractions be completely inline. QSizePolicy is a good example. It's full now. If ever we need to add a new member, we need QSizePolicyV2. Note that I'm not saying that we should version QString or other such core classes like this. This is completely impractical. But we have tons of small classes that are used in only a handful of APIs and they would definitely benefit from this. QStyleOption, QSizePolicy, most QSsl value types. Stuff like Q*DialogOptions. There's just no reason to pay the pimpl price for these anymore. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Thu Mar 30 11:21:35 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 30 Mar 2017 11:21:35 +0200 Subject: [Development] supported compilers in 5.10? Message-ID: <201703301121.35735.marc.mutz@kdab.com> Hi, Can we drop GCC 4.7 from the list of supported compilers for 5.10? It has a bug that makes writing constexpr classes like QSizePolicy, QUuid, ... very annoying: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54922 If we can drop MSVC 2013, too, we can start to use char16_t unconditionlly, which will make QStringViewLiteral obsolete, as we can just write u"foo" everywhere. It will also simplify a lot of other code that currently needs to fall back to wchar_t on Windows / MSVC 2013. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From olivier at woboq.com Thu Mar 30 11:31:11 2017 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 30 Mar 2017 11:31:11 +0200 Subject: [Development] inline namespaces as a versioning tool (was: Re: QList) In-Reply-To: <201703301108.46468.marc.mutz@kdab.com> References: <9516701.cu2aKLv5Fy@maurice> <201703301108.46468.marc.mutz@kdab.com> Message-ID: <53266026.SN4cGoEzm9@maurice> On Donnerstag, 30. März 2017 11:08:45 CEST Marc Mutz wrote: > On Thursday 30 March 2017 08:41:51 Olivier Goffart wrote: > > On Donnerstag, 30. März 2017 08:32:24 CEST Marc Mutz wrote: > > > On Thursday 30 March 2017 08:18:52 Olivier Goffart wrote: > > > > On Donnerstag, 30. März 2017 07:20:11 CEST Marc Mutz wrote: > > > > > On Wednesday 29 March 2017 22:12:30 Thiago Macieira wrote: > > > > > > On quarta-feira, 29 de março de 2017 11:11:58 PDT Marc Mutz wrote: > > > > > > > Keyword: inline namespaces. This is the C++ mechanism for API > > > > > > > versioning. It allows to make that totally transparent. Why you > > > > > > > find that so odd as to be lacking for words is beyond me. > > > > > > > > > > > > Inline namespaces do not solve the binary compatibility problem. > > > > > > They should not be used in Qt API for versioning. > > > > > > > > > > > > Instead, do what you said before: create a V2 class. > > > > > > > > > > Since the two are totally identical, except that inline namespaces > > > > > are transparent to the user, please explain what leads you to this > > > > > distinction. > > > > > > > > Library 1: > > > > inline namespace v1 { class Foo {}; } > > > > > > > > Library 2: > > > > LIBRARY2_EXPORT void registerPlugin(Foo*); > > > > > > > > -> symbol gets mangled as "registerPlugin(v1::Foo*)" > > > > > > > > Application: > > > > registerPlugin(new Foo); > > > > > > > > -> calls exported symbol "registerPlugin(v1::Foo*)" > > > > > > > > When Library 1 puts Foo in the v2 inline namespace, recompile > > > > Library2 > > > > and > > > > the exported symbol becomes "registerPlugin(v2::Foo*)". If Application > > > > is not recompiled, it will not work as the old symbol is no longer > > > > found. > > > > > > Well, of couse. That's like removing the QFoo overload when you add > > > QFooV2. Don't do that. You need to keep the v1::Foo definition as well > > > as the v1::Foo overload, just as you need to keep the QFoo definition > > > and the QFoo overload, when you add v2. > > > > What I meant is that Library 1 becomes, in its next version > > > > namespace v1 { class Foo{}; } > > inline namespace v2 { class Foo{}; } > > > > It keeps v1::Foo, but puts v2::Foo in the inline namespace. > > > > If you don't use "inline namespace v2", that means users needs to > > explicitly use v2::Foo to use the new features. So it is no longer > > "transparent to the user" > > Ok, no. > > library V1: > > inline // this inline is optional for V1 - users with compilers without > // support for them need to write v1:: explicitly, or it can be > // reasonably emulated with a ... > namespace v1 { class Foo{ int i, }; } > // ... using v1::Foo, here > LIB_EXPORT void useFoo(Foo); // actually v1::Foo > > user V1: > > useFoo(Foo{}); // actually v1::Foo > > library V2: > > namespace v1 { class Foo{ int i; } } // from V1 of library > inline > namespace v2 { class Foo{ v1::Foo f; double d; } // adds a double > member, > // reuses v1::Foo > LIB_EXPORT void useFoo(v1::Foo); // from V1 of library > LIB_EXPORT void useFoo(Foo); // actually v2::Foo > > user V2 @ library V2: > > useFoo(Foo{}); // actually v2::Foo > > user V1 @ library V2: > > (compiled and continuing to run as) useFoo(v1::Foo{}); > > -> totally transparent, BC and SC > > Where's my mistake? That works fine as long as there is only one library involved. It stops working once the library is used in the ABI of another library. Example: Qt used by KDE frameworks used by applications. Or stdlib used in the ABI of Qt. Imaging we have a ExLibrary that links against Library: ExLibrary: EXLIB_EXPORT void exUseFoo(Foo); EXLIB_EXPORT Foo exGetDefaultFoo(); ExLibrary @ Library V1 -> exports "exUseFoo(v1::Foo)" -> exports "exGetDefaultFoo()" returning an object v1::Foo ExLibrary @ Library V2 -> exports only "exUseFoo(v2::Foo)" -> still exports "exGetDefaultFoo()", but it returns a v2::Foo now, which does not have the same layout The problem is: as ExLibrary gets recompiled against the new version of Library, it no longer exports the old symbols. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From marc.mutz at kdab.com Thu Mar 30 11:40:53 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 30 Mar 2017 11:40:53 +0200 Subject: [Development] inline namespaces as a versioning tool (was: Re: QList) In-Reply-To: <53266026.SN4cGoEzm9@maurice> References: <201703301108.46468.marc.mutz@kdab.com> <53266026.SN4cGoEzm9@maurice> Message-ID: <201703301140.53822.marc.mutz@kdab.com> On Thursday 30 March 2017 11:31:11 Olivier Goffart wrote: > On Donnerstag, 30. März 2017 11:08:45 CEST Marc Mutz wrote: > > On Thursday 30 March 2017 08:41:51 Olivier Goffart wrote: > > > On Donnerstag, 30. März 2017 08:32:24 CEST Marc Mutz wrote: > > > > On Thursday 30 March 2017 08:18:52 Olivier Goffart wrote: > > > > > On Donnerstag, 30. März 2017 07:20:11 CEST Marc Mutz wrote: > > > > > > On Wednesday 29 March 2017 22:12:30 Thiago Macieira wrote: > > > > > > > On quarta-feira, 29 de março de 2017 11:11:58 PDT Marc Mutz wrote: > > > > > > > > Keyword: inline namespaces. This is the C++ mechanism for API > > > > > > > > versioning. It allows to make that totally transparent. Why > > > > > > > > you find that so odd as to be lacking for words is beyond > > > > > > > > me. > > > > > > > > > > > > > > Inline namespaces do not solve the binary compatibility > > > > > > > problem. They should not be used in Qt API for versioning. > > > > > > > > > > > > > > Instead, do what you said before: create a V2 class. > > > > > > > > > > > > Since the two are totally identical, except that inline > > > > > > namespaces are transparent to the user, please explain what > > > > > > leads you to this distinction. > > > > > > > > > > Library 1: > > > > > inline namespace v1 { class Foo {}; } > > > > > > > > > > Library 2: > > > > > LIBRARY2_EXPORT void registerPlugin(Foo*); > > > > > > > > > > -> symbol gets mangled as "registerPlugin(v1::Foo*)" > > > > > > > > > > Application: > > > > > registerPlugin(new Foo); > > > > > > > > > > -> calls exported symbol "registerPlugin(v1::Foo*)" > > > > > > > > > > When Library 1 puts Foo in the v2 inline namespace, recompile > > > > > Library2 > > > > > and > > > > > the exported symbol becomes "registerPlugin(v2::Foo*)". If > > > > > Application is not recompiled, it will not work as the old symbol > > > > > is no longer found. > > > > > > > > Well, of couse. That's like removing the QFoo overload when you add > > > > QFooV2. Don't do that. You need to keep the v1::Foo definition as > > > > well as the v1::Foo overload, just as you need to keep the QFoo > > > > definition and the QFoo overload, when you add v2. > > > > > > What I meant is that Library 1 becomes, in its next version > > > > > > namespace v1 { class Foo{}; } > > > inline namespace v2 { class Foo{}; } > > > > > > It keeps v1::Foo, but puts v2::Foo in the inline namespace. > > > > > > If you don't use "inline namespace v2", that means users needs to > > > explicitly use v2::Foo to use the new features. So it is no longer > > > "transparent to the user" > > > > Ok, no. > > > > library V1: > > inline // this inline is optional for V1 - users with compilers > > without > > > > // support for them need to write v1:: explicitly, or it can > > be // reasonably emulated with a ... > > > > namespace v1 { class Foo{ int i, }; } > > > > // ... using v1::Foo, here > > > > LIB_EXPORT void useFoo(Foo); // actually v1::Foo > > > > user V1: > > useFoo(Foo{}); // actually v1::Foo > > > > library V2: > > namespace v1 { class Foo{ int i; } } // from V1 of library > > inline > > namespace v2 { class Foo{ v1::Foo f; double d; } // adds a double > > > > member, > > > > // reuses v1::Foo > > > > LIB_EXPORT void useFoo(v1::Foo); // from V1 of library > > LIB_EXPORT void useFoo(Foo); // actually v2::Foo > > > > user V2 @ library V2: > > useFoo(Foo{}); // actually v2::Foo > > > > user V1 @ library V2: > > (compiled and continuing to run as) useFoo(v1::Foo{}); > > > > -> totally transparent, BC and SC > > > > Where's my mistake? > > That works fine as long as there is only one library involved. > It stops working once the library is used in the ABI of another library. > > Example: Qt used by KDE frameworks used by applications. Or stdlib used in > the ABI of Qt. > > > > Imaging we have a ExLibrary that links against Library: > > ExLibrary: > EXLIB_EXPORT void exUseFoo(Foo); > EXLIB_EXPORT Foo exGetDefaultFoo(); > > ExLibrary @ Library V1 > -> exports "exUseFoo(v1::Foo)" > -> exports "exGetDefaultFoo()" returning an object v1::Foo > > > ExLibrary @ Library V2 > -> exports only "exUseFoo(v2::Foo)" > -> still exports "exGetDefaultFoo()", but it returns a v2::Foo now, which > does not have the same layout > > The problem is: as ExLibrary gets recompiled against the new version of > Library, it no longer exports the old symbols. Ok, not 100% transparent in all cases, then. But a symbol comparison like we do before a release will highlight this. Anyway, apart from transparency: how is that different from QFoo followed up by QFooV2? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From ville.voutilainen at gmail.com Thu Mar 30 11:43:17 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Thu, 30 Mar 2017 12:43:17 +0300 Subject: [Development] supported compilers in 5.10? In-Reply-To: <201703301121.35735.marc.mutz@kdab.com> References: <201703301121.35735.marc.mutz@kdab.com> Message-ID: On 30 March 2017 at 12:21, Marc Mutz wrote: > Hi, > > Can we drop GCC 4.7 from the list of supported compilers for 5.10? It has a > bug that makes writing constexpr classes like QSizePolicy, QUuid, ... very > annoying: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54922 Yes please. Is there some long-term support distro that still ships with 4.7 that we care about? > If we can drop MSVC 2013, too, we can start to use char16_t unconditionlly, > which will make QStringViewLiteral obsolete, as we can just write u"foo" > everywhere. It will also simplify a lot of other code that currently needs to > fall back to wchar_t on Windows / MSVC 2013. It would certainly be nice not to have to worry about working around the various problems with MSVC 2013. From olivier at woboq.com Thu Mar 30 11:54:42 2017 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 30 Mar 2017 11:54:42 +0200 Subject: [Development] supported compilers in 5.10? In-Reply-To: <201703301121.35735.marc.mutz@kdab.com> References: <201703301121.35735.marc.mutz@kdab.com> Message-ID: <11315255.3ThuH6AFVL@maurice> On Donnerstag, 30. März 2017 11:21:35 CEST Marc Mutz wrote: > Hi, > > Can we drop GCC 4.7 from the list of supported compilers for 5.10? It has a > bug that makes writing constexpr classes like QSizePolicy, QUuid, ... very > annoying: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54922 > > If we can drop MSVC 2013, too, we can start to use char16_t unconditionlly, > which will make QStringViewLiteral obsolete, as we can just write u"foo" > everywhere. It will also simplify a lot of other code that currently needs > to fall back to wchar_t on Windows / MSVC 2013. Where is the list of supported compiler? I can't find it. If dropping 4.7 and MSVC2013, can we require GCC 4.8.1? Then we could use reference qualifier for function unconditionally and we can avoid doing ugly workaround like QNetworkDatagram::makeReply does. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From giuseppe.dangelo at kdab.com Thu Mar 30 12:14:31 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 30 Mar 2017 12:14:31 +0200 Subject: [Development] supported compilers in 5.10? In-Reply-To: References: <201703301121.35735.marc.mutz@kdab.com> Message-ID: <65e27fa2-6ab7-636d-90e6-44a943e5c1a7@kdab.com> Il 30/03/2017 11:43, Ville Voutilainen ha scritto: > On 30 March 2017 at 12:21, Marc Mutz wrote: >> Hi, >> >> Can we drop GCC 4.7 from the list of supported compilers for 5.10? It has a >> bug that makes writing constexpr classes like QSizePolicy, QUuid, ... very >> annoying: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54922 > > Yes please. Is there some long-term support distro that still ships > with 4.7 that we care about? No, AFAICS: https://doc.qt.io/qt-5/supported-platforms-and-configurations.html > >> If we can drop MSVC 2013, too, we can start to use char16_t unconditionlly, >> which will make QStringViewLiteral obsolete, as we can just write u"foo" >> everywhere. It will also simplify a lot of other code that currently needs to >> fall back to wchar_t on Windows / MSVC 2013. > > It would certainly be nice not to have to worry about working around > the various problems with MSVC 2013. I would favour to support only the latest two compilers (so 2017 and 2015), but I've got the feeling it might be too early. People using MSVC move *slowly* to the next compiler... My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From marc.mutz at kdab.com Thu Mar 30 13:14:53 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 30 Mar 2017 13:14:53 +0200 Subject: [Development] supported compilers in 5.10? In-Reply-To: <11315255.3ThuH6AFVL@maurice> References: <201703301121.35735.marc.mutz@kdab.com> <11315255.3ThuH6AFVL@maurice> Message-ID: <201703301314.54287.marc.mutz@kdab.com> On Thursday 30 March 2017 11:54:42 Olivier Goffart wrote: > On Donnerstag, 30. März 2017 11:21:35 CEST Marc Mutz wrote: > > Hi, > > > > Can we drop GCC 4.7 from the list of supported compilers for 5.10? It has > > a bug that makes writing constexpr classes like QSizePolicy, QUuid, ... > > very annoying: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54922 > > > > If we can drop MSVC 2013, too, we can start to use char16_t > > unconditionlly, which will make QStringViewLiteral obsolete, as we can > > just write u"foo" everywhere. It will also simplify a lot of other code > > that currently needs to fall back to wchar_t on Windows / MSVC 2013. > > Where is the list of supported compiler? I can't find it. > > If dropping 4.7 and MSVC2013, can we require GCC 4.8.1? Then we could use > reference qualifier for function unconditionally and we can avoid doing > ugly workaround like QNetworkDatagram::makeReply does. The latest I found was dist/changes-5.7.0, which has - Starting with Qt 5.7, Qt requires a C++11 compiler with support for C++11 atomics. This affects user code too: Qt headers no longer compile with a C++98 compiler. The minimum compiler versions for this release are: * GCC 4.7 * Clang 3.4 (found in XCode 5.1) * Microsoft Visual Studio 2013 IIRC, we didn't up the minimum compiler versions since then. dist/changes-5.6.0 is a bit more concrete: **************************************************************************** * Future Direction Notice * **************************************************************************** [...] - Qt 5.7 will begin requiring certain C++11 features in order to compile. The minimum compiler versions for that release will be: * Clang 3.4 (included in XCode 5.1) * GCC 4.7 * Intel C++ Composer XE 2013 SP1 (compiler version 14.0) * Microsoft Visual Studio 2013 (compiler version 19.0) Another reason to remove MSVC 2013: 2015 has atomic + constexpr, afaik, so we could finally drop QAtomic* in favour of std::atomic in the implementation and deprecate QAtomic*. Ohhhh, there are soooo many reasons to drop MSVC 2013. I will stop here before I get carried away: https://msdn.microsoft.com/en-us/library/hh567368.aspx Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From announce at qt-project.org Thu Mar 30 13:19:19 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Thu, 30 Mar 2017 11:19:19 +0000 Subject: [Development] [Announce] Qt Creator 4.3.0 Beta released Message-ID: We are happy to announce the release of Qt Creator 4.3 Beta! https://blog.qt.io/blog/2017/03/30/qt-creator-4-3-beta-released/ -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From rafael.roquetto at kdab.com Thu Mar 30 14:08:58 2017 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Thu, 30 Mar 2017 09:08:58 -0300 Subject: [Development] supported compilers in 5.10? In-Reply-To: <65e27fa2-6ab7-636d-90e6-44a943e5c1a7@kdab.com> References: <201703301121.35735.marc.mutz@kdab.com> <65e27fa2-6ab7-636d-90e6-44a943e5c1a7@kdab.com> Message-ID: <20170330120857.GA5155@orion> On Thu, Mar 30, 2017 at 12:14:31PM +0200, Giuseppe D'Angelo wrote: > Il 30/03/2017 11:43, Ville Voutilainen ha scritto: > > On 30 March 2017 at 12:21, Marc Mutz wrote: > >> Hi, > >> > >> Can we drop GCC 4.7 from the list of supported compilers for 5.10? It has a > >> bug that makes writing constexpr classes like QSizePolicy, QUuid, ... very > >> annoying: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54922 > > > > Yes please. Is there some long-term support distro that still ships > > with 4.7 that we care about? > > No, AFAICS: > > https://doc.qt.io/qt-5/supported-platforms-and-configurations.html Sorry, but QNX 6.6 is based on GCC 4.7. With OEMs barely finishing to migrate from 6.5, I would not advise to drop QNX 6.6 support yet. QNX 7 has just launched, so I expect a couple of years for vendors to catch up. I mean it! There are lots of vendors constrained by their underlying platform, and telling them to upgrade their version that soon will not work. Unfortunately for us, their development cycle seems to be much, much longer than ours. We need to find a compromise, a balance, and in my opinion, dropping QNX 6.6 support in Qt 5.10 is not reasonable. Perhaps for Qt 6, it would be. But I may be wrong. If the only problem is the bug Marc mentioned above, to me this is not even a trade-off. We should just work around the bug for QNX, if possible, and move on. Rafael -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3599 bytes Desc: not available URL: From mwoehlke.floss at gmail.com Thu Mar 30 16:32:58 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Thu, 30 Mar 2017 10:32:58 -0400 Subject: [Development] QList In-Reply-To: <549911490826831@web19j.yandex.ru> References: <58DBE788.50609@gmail.com> <20170329231730.D1F6.6F0322A@gmail.com> <549911490826831@web19j.yandex.ru> Message-ID: <58DD171A.9040307@gmail.com> On 2017-03-29 18:33, Konstantin Tokarev wrote: > 30.03.2017, 00:17, "Philippe" : >> And being able to use a QVector with O(1) by-value assigment, thanks to >> COW, make it easy to use QVectors "as primitive types", with no >> reasonning effort. > > With move semantics you can achieve this without CoW in a more explicit way I don't think we all agree that "in a more explicit way" is a *feature*. -- Matthew From thiago.macieira at intel.com Thu Mar 30 17:41:01 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 30 Mar 2017 08:41:01 -0700 Subject: [Development] inline namespaces as a versioning tool (was: Re: QList) In-Reply-To: <201703301140.53822.marc.mutz@kdab.com> References: <53266026.SN4cGoEzm9@maurice> <201703301140.53822.marc.mutz@kdab.com> Message-ID: <4658787.OzSe6lAugy@tjmaciei-mobl1> On quinta-feira, 30 de março de 2017 02:40:53 PDT Marc Mutz wrote: > Ok, not 100% transparent in all cases, then. But a symbol comparison like we > do before a release will highlight this. I'm assuming you're talking here about the library whose binary compatibility gets broken: we do a header diff, not a symbol diff. We wouldn't catch this at the headerdiff time because the namespace is inline, so the functions that were affected were not changed at all. In fact, the headers that declare those functions may be completely unmodified. Aleksey does run the ABI checker tool that does show symbols. Show of hands, how many of you have clicked his links in the last year? Now, if you're talking about the library that has the inline namespace, then yes, we'd catch it. We'd see a change in inline namespace. And our BC rules should require is to revert that change and keep the inline back to the original. > Anyway, apart from transparency: how is that different from QFoo followed up > by QFooV2? Implicit (opt-out) vs explicit (opt-in). One is a silent change downstream and causes silent breakage unless everything gets recompiled. Even if you know that this is a problem and is going to happen, you can't prepare for it until the new class appears, so a recompilation is still needed. That's what happened in the std::string vs std::__cxx11::string problem. In the other, it's explicit. Code that used to work continues to work, whether it's recompiled or not. There's no need to insert code to prepare for the update and recompile at the right time. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 30 17:43:24 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 30 Mar 2017 08:43:24 -0700 Subject: [Development] supported compilers in 5.10? In-Reply-To: <201703301314.54287.marc.mutz@kdab.com> References: <201703301121.35735.marc.mutz@kdab.com> <11315255.3ThuH6AFVL@maurice> <201703301314.54287.marc.mutz@kdab.com> Message-ID: <2739848.ku14Jbb6u0@tjmaciei-mobl1> On quinta-feira, 30 de março de 2017 04:14:53 PDT Marc Mutz wrote: > * Microsoft Visual Studio 2013 (compiler version 19.0) This was 18.0.... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alex at vikingsoft.eu Thu Mar 30 22:32:35 2017 From: alex at vikingsoft.eu (Alejandro Exojo) Date: Thu, 30 Mar 2017 22:32:35 +0200 Subject: [Development] QList In-Reply-To: References: <58DBE788.50609@gmail.com> Message-ID: <17970798.qKmmoPtyQb@walt> On Wednesday 29 March 2017 20:11:58 Marc Mutz wrote: > I would really, really > like to know why QVector is easier to use? Because it has indexOf()? > Seriously, now? Because it has _lots_ of easy to use member functions, and another kind of iterator that is also easier to use for some, and good documentation. I'm not making this stuff up: http://stackoverflow.com/questions/571394/ Hundreds of votes for something immensely simple, that with Qt containers is also immensely more readable. Ease of use has a lot more value than performance to many people. A thought: how many comments did get the blog post that you did on making QRegion iterable? And how many the one about the removal of the foreach macro? -- Viking Software, Qt and C++ developers for hire http://www.vikingsoft.eu From marc.mutz at kdab.com Fri Mar 31 08:46:12 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 31 Mar 2017 08:46:12 +0200 Subject: [Development] QList In-Reply-To: <17970798.qKmmoPtyQb@walt> References: <17970798.qKmmoPtyQb@walt> Message-ID: <201703310846.12684.marc.mutz@kdab.com> On Thursday 30 March 2017 22:32:35 Alejandro Exojo wrote: > On Wednesday 29 March 2017 20:11:58 Marc Mutz wrote: > > I would really, really > > like to know why QVector is easier to use? Because it has indexOf()? > > Seriously, now? > > Because it has _lots_ of easy to use member functions, and another kind of > iterator that is also easier to use for some, and good documentation. I'm > not making this stuff up: > > http://stackoverflow.com/questions/571394/ Oh, I can play this game, too: http://stackoverflow.com/questions/16559655/ http://stackoverflow.com/questions/38262041/ http://stackoverflow.com/questions/10153658/ http://stackoverflow.com/questions/35811053/ > Hundreds of votes for something immensely simple, that with Qt containers > is also immensely more readable. Ease of use has a lot more value than > performance to many people. A thought: how many comments did get the blog > post that you did on making QRegion iterable? And how many the one about > the removal of the foreach macro? -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From Simon.Hausmann at qt.io Fri Mar 31 08:57:50 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 31 Mar 2017 06:57:50 +0000 Subject: [Development] QList In-Reply-To: <201703310846.12684.marc.mutz@kdab.com> References: <17970798.qKmmoPtyQb@walt>,<201703310846.12684.marc.mutz@kdab.com> Message-ID: Hi, To me this appears to be comparing the questions that new learning programmers have with questions of seasoned C++ programmers. I understand that we should cater both with Qt, but the topic at this point of the thread is the former group, not the latter. Simon > On 31. Mar 2017, at 08:41, Marc Mutz wrote: > >> On Thursday 30 March 2017 22:32:35 Alejandro Exojo wrote: >>> On Wednesday 29 March 2017 20:11:58 Marc Mutz wrote: >>> I would really, really >>> like to know why QVector is easier to use? Because it has indexOf()? >>> Seriously, now? >> >> Because it has _lots_ of easy to use member functions, and another kind of >> iterator that is also easier to use for some, and good documentation. I'm >> not making this stuff up: >> >> http://stackoverflow.com/questions/571394/ > > Oh, I can play this game, too: > > http://stackoverflow.com/questions/16559655/ > http://stackoverflow.com/questions/38262041/ > http://stackoverflow.com/questions/10153658/ > http://stackoverflow.com/questions/35811053/ > >> Hundreds of votes for something immensely simple, that with Qt containers >> is also immensely more readable. Ease of use has a lot more value than >> performance to many people. A thought: how many comments did get the blog >> post that you did on making QRegion iterable? And how many the one about >> the removal of the foreach macro? > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Fri Mar 31 09:43:11 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 31 Mar 2017 09:43:11 +0200 Subject: [Development] QList In-Reply-To: References: <201703310846.12684.marc.mutz@kdab.com> Message-ID: <201703310943.12538.marc.mutz@kdab.com> On Friday 31 March 2017 08:57:50 Simon Hausmann wrote: > Hi, > > To me this appears to be comparing the questions that new learning > programmers have with questions of seasoned C++ programmers. I understand > that we should cater both with Qt, but the topic at this point of the > thread is the former group, not the latter. Which questions do you think are beginner's and which ones are seasoned developer's questions? What criteria do you use to put one in one bin and the other in the other? People that use C++ without Qt have excellent online documentation, too[1]. And if they peruse it to find out how to fill a vector from a C array, then they will come across assign() and the range constructors. They start with Qt, and they miss these things. Everyone learning C++ with the 2011 edition of the standard will be used to just throwing ranged-for at every container and suddenly a fat man in a YouTube video tells them that doing so with Qt containers performs a deep copy. Sure they have questions. So, no, Qt containers are not more novice-friendly than STL containers, nor vice versa. They all leave something to be desired. Picking one part of the API and saying "this is why it's better/worse" will predicably be responded to by showing the other half of the picture. But one thing the STL has going for it: once you do learn it, it lets you go farther with what you have learned than Qt. Once you learned the find() algorithm, you can apply it to every C++ container in the world, incl. C arrays and Qt containers. Incl. QFuture, which is a Qt container that - surprise - doesn't have indexOf() and contains(). Thanks, Marc [1] even better than Qt's, these days, since cppreference.com clearly shows what's available in which C++ version while Qt hides all but the latest documentation, which only describes the current state of affairs. > Simon > > > On 31. Mar 2017, at 08:41, Marc Mutz wrote: > >> On Thursday 30 March 2017 22:32:35 Alejandro Exojo wrote: > >>> On Wednesday 29 March 2017 20:11:58 Marc Mutz wrote: > >>> I would really, really > >>> like to know why QVector is easier to use? Because it has indexOf()? > >>> Seriously, now? > >> > >> Because it has _lots_ of easy to use member functions, and another kind > >> of iterator that is also easier to use for some, and good > >> documentation. I'm not making this stuff up: > >> > >> http://stackoverflow.com/questions/571394/ > > > > Oh, I can play this game, too: > > > > http://stackoverflow.com/questions/16559655/ > > http://stackoverflow.com/questions/38262041/ > > http://stackoverflow.com/questions/10153658/ > > http://stackoverflow.com/questions/35811053/ > > > >> Hundreds of votes for something immensely simple, that with Qt > >> containers is also immensely more readable. Ease of use has a lot more > >> value than performance to many people. A thought: how many comments did > >> get the blog post that you did on making QRegion iterable? And how many > >> the one about the removal of the foreach macro? -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From annulen at yandex.ru Fri Mar 31 09:43:18 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 31 Mar 2017 10:43:18 +0300 Subject: [Development] QList In-Reply-To: <201703310943.12538.marc.mutz@kdab.com> References: <201703310846.12684.marc.mutz@kdab.com> <201703310943.12538.marc.mutz@kdab.com> Message-ID: <3776251490946198@web15m.yandex.ru> 31.03.2017, 10:38, "Marc Mutz" : > On Friday 31 March 2017 08:57:50 Simon Hausmann wrote: >>  Hi, >> >>  To me this appears to be comparing the questions that new learning >>  programmers have with questions of seasoned C++ programmers. I understand >>  that we should cater both with Qt, but the topic at this point of the >>  thread is the former group, not the latter. > > Which questions do you think are beginner's and which ones are seasoned > developer's questions? > > What criteria do you use to put one in one bin and the other in the other? > > People that use C++ without Qt have excellent online documentation, too[1]. > And if they peruse it to find out how to fill a vector from a C array, then > they will come across assign() and the range constructors. They start with Qt, > and they miss these things. > > Everyone learning C++ with the 2011 edition of the standard will be used to > just throwing ranged-for at every container and suddenly a fat man in a > YouTube video tells them that doing so with Qt containers performs a deep > copy. Sure they have questions. > > So, no, Qt containers are not more novice-friendly than STL containers, nor > vice versa. They all leave something to be desired. Picking one part of the > API and saying "this is why it's better/worse" will predicably be responded to > by showing the other half of the picture. > > But one thing the STL has going for it: once you do learn it, it lets you go > farther with what you have learned than Qt. Once you learned the find() > algorithm, you can apply it to every C++ container in the world, incl. C > arrays and Qt containers. Incl. QFuture, which is a Qt container that - > surprise - doesn't have indexOf() and contains(). > > Thanks, > Marc > > [1] even better than Qt's, these days, since cppreference.com clearly shows > what's available in which C++ version while Qt hides all but the latest > documentation, which only describes the current state of affairs. Each Qt release is shipped with documentation. Also, there is \since. > >>  Simon >> >>  > On 31. Mar 2017, at 08:41, Marc Mutz wrote: >>  >> On Thursday 30 March 2017 22:32:35 Alejandro Exojo wrote: >>  >>> On Wednesday 29 March 2017 20:11:58 Marc Mutz wrote: >>  >>> I would really, really >>  >>> like to know why QVector is easier to use? Because it has indexOf()? >>  >>> Seriously, now? >>  >> >>  >> Because it has _lots_ of easy to use member functions, and another kind >>  >> of iterator that is also easier to use for some, and good >>  >> documentation. I'm not making this stuff up: >>  >> >>  >> http://stackoverflow.com/questions/571394/ >>  > >>  > Oh, I can play this game, too: >>  > >>  > http://stackoverflow.com/questions/16559655/ >>  > http://stackoverflow.com/questions/38262041/ >>  > http://stackoverflow.com/questions/10153658/ >>  > http://stackoverflow.com/questions/35811053/ >>  > >>  >> Hundreds of votes for something immensely simple, that with Qt >>  >> containers is also immensely more readable. Ease of use has a lot more >>  >> value than performance to many people. A thought: how many comments did >>  >> get the blog post that you did on making QRegion iterable? And how many >>  >> the one about the removal of the foreach macro? > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From annulen at yandex.ru Fri Mar 31 10:12:44 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 31 Mar 2017 11:12:44 +0300 Subject: [Development] QList In-Reply-To: <58DD171A.9040307@gmail.com> References: <58DBE788.50609@gmail.com> <20170329231730.D1F6.6F0322A@gmail.com> <549911490826831@web19j.yandex.ru> <58DD171A.9040307@gmail.com> Message-ID: <4066611490947964@web35j.yandex.ru> 30.03.2017, 17:33, "Matthew Woehlke" : > On 2017-03-29 18:33, Konstantin Tokarev wrote: >>  30.03.2017, 00:17, "Philippe" : >>>  And being able to use a QVector with O(1) by-value assigment, thanks to >>>  COW, make it easy to use QVectors "as primitive types", with no >>>  reasonning effort. >> >>  With move semantics you can achieve this without CoW in a more explicit way > > I don't think we all agree that "in a more explicit way" is a *feature*. Go write code in JS then. It manages even more things implicitly than just lifetime of your data objects, and has much less syntactic overhead. > > -- > Matthew > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From philwave at gmail.com Fri Mar 31 10:34:54 2017 From: philwave at gmail.com (Philippe) Date: Fri, 31 Mar 2017 10:34:54 +0200 Subject: [Development] QList In-Reply-To: <4066611490947964@web35j.yandex.ru> References: <58DD171A.9040307@gmail.com> <4066611490947964@web35j.yandex.ru> Message-ID: <20170331103453.E361.6F0322A@gmail.com> On Fri, 31 Mar 2017 11:12:44 +0300 Konstantin Tokarev wrote: > 30.03.2017, 17:33, "Matthew Woehlke" : > > On 2017-03-29 18:33, Konstantin Tokarev wrote: > >>  30.03.2017, 00:17, "Philippe" : > >>>  And being able to use a QVector with O(1) by-value assigment, thanks to > >>>  COW, make it easy to use QVectors "as primitive types", with no > >>>  reasonning effort. > >> > >>  With move semantics you can achieve this without CoW in a more explicit way > > > > I don't think we all agree that "in a more explicit way" is a *feature*. > > Go write code in JS then. It manages even more things implicitly than just lifetime of your > data objects, and has much less syntactic overhead. You quote an extreme case with JS. Software development is all about tradeoffs... Qt has put so far the convenience cursor to the right place, IMHO. I will even say this is the number #1 quality of Qt. Philippe From marc.mutz at kdab.com Fri Mar 31 10:56:53 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 31 Mar 2017 10:56:53 +0200 Subject: [Development] QList In-Reply-To: <3776251490946198@web15m.yandex.ru> References: <201703310943.12538.marc.mutz@kdab.com> <3776251490946198@web15m.yandex.ru> Message-ID: <201703311056.54007.marc.mutz@kdab.com> On Friday 31 March 2017 09:43:18 Konstantin Tokarev wrote: > 31.03.2017, 10:38, "Marc Mutz" : [...] > > [1] even better than Qt's, these days, since cppreference.com clearly > > shows what's available in which C++ version while Qt hides all but the > > latest documentation, which only describes the current state of affairs. > > Each Qt release is shipped with documentation. That doesn't help if you develop software that's supposed to be compatible with multiple Qt versions. Even if you install all Qt releases, the fact that you have separate documents per version makes finding past changes very hard. > Also, there is \since. But no \until. I try to put this in the docs, and sometimes I succeeded, but I've also been -1ed for trying already. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Fri Mar 31 10:59:19 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 31 Mar 2017 10:59:19 +0200 Subject: [Development] QList In-Reply-To: <201703311056.54007.marc.mutz@kdab.com> References: <3776251490946198@web15m.yandex.ru> <201703311056.54007.marc.mutz@kdab.com> Message-ID: <201703311059.20360.marc.mutz@kdab.com> On Friday 31 March 2017 10:56:53 Marc Mutz wrote: > But no \until. I try to put this in the docs, and sometimes I succeeded, > but I've also been -1ed for trying already. Before you ask: http://doc.qt.io/qt-5/qsharedpointer.html#create-1 is a successful attempt. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From Martin.Smith at qt.io Fri Mar 31 10:59:35 2017 From: Martin.Smith at qt.io (Martin Smith) Date: Fri, 31 Mar 2017 08:59:35 +0000 Subject: [Development] QList In-Reply-To: <201703311056.54007.marc.mutz@kdab.com> References: <201703310943.12538.marc.mutz@kdab.com> <3776251490946198@web15m.yandex.ru>, <201703311056.54007.marc.mutz@kdab.com> Message-ID: >But no \until. I try to put this in the docs, and sometimes I succeeded, but >I've also been -1ed for trying already. I have never been asked to add \until to qdoc. martin ________________________________ From: Development on behalf of Marc Mutz Sent: Friday, March 31, 2017 10:56:53 AM To: development at qt-project.org Subject: Re: [Development] QList On Friday 31 March 2017 09:43:18 Konstantin Tokarev wrote: > 31.03.2017, 10:38, "Marc Mutz" : [...] > > [1] even better than Qt's, these days, since cppreference.com clearly > > shows what's available in which C++ version while Qt hides all but the > > latest documentation, which only describes the current state of affairs. > > Each Qt release is shipped with documentation. That doesn't help if you develop software that's supposed to be compatible with multiple Qt versions. Even if you install all Qt releases, the fact that you have separate documents per version makes finding past changes very hard. > Also, there is \since. But no \until. I try to put this in the docs, and sometimes I succeeded, but I've also been -1ed for trying already. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael.roquetto at kdab.com Fri Mar 31 14:15:39 2017 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Fri, 31 Mar 2017 09:15:39 -0300 Subject: [Development] QNX 6.6 on Qt 5.10 Message-ID: <20170331121538.GA7480@orion> Hello, Since Marc has already the subject of which compilers need to be supported for 5.10, I would like to take this opportunity to explicitly ask: what is our take for QNX 6.6? Or even better, until which Qt release do we plan to support it? I am currently working on ensuring QNX 7 at least builds on the dev branch, but 6.6 also seems to be broken, and I wanted to know whether I should care about fixing it. Personally, as I have stated before, I don't think it would be a good idea to drop 6.6 already, but this is not my call. So, what do you think? Please advise. Thanks, Rafael -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3599 bytes Desc: not available URL: From lars.knoll at qt.io Fri Mar 31 14:48:40 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 31 Mar 2017 12:48:40 +0000 Subject: [Development] QNX 6.6 on Qt 5.10 In-Reply-To: <20170331121538.GA7480@orion> References: <20170331121538.GA7480@orion> Message-ID: Hi Rafael, I’d agree with you that it’s too early to drop QNX 6.6, even though I understand that people would want to drop gcc 4.7. Is there a chance QNX 6.6 will get a toolchain update at some point? Lars > On 31 Mar 2017, at 14:15, Rafael Roquetto wrote: > > Hello, > > Since Marc has already the subject of which compilers need to be supported for > 5.10, I would like to take this opportunity to explicitly ask: what is our > take for QNX 6.6? Or even better, until which Qt release do we plan to support > it? I am currently working on ensuring QNX 7 at least builds on the dev > branch, but 6.6 also seems to be broken, and I wanted to know whether I should > care about fixing it. Personally, as I have stated before, I don't think it > would be a good idea to drop 6.6 already, but this is not my call. > > So, what do you think? Please advise. > > Thanks, > Rafael > -- > Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From ville.voutilainen at gmail.com Fri Mar 31 15:09:52 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Fri, 31 Mar 2017 16:09:52 +0300 Subject: [Development] QNX 6.6 on Qt 5.10 In-Reply-To: References: <20170331121538.GA7480@orion> Message-ID: On 31 March 2017 at 15:48, Lars Knoll wrote: > Hi Rafael, > > I’d agree with you that it’s too early to drop QNX 6.6, even though I understand that people would want to drop gcc 4.7. Is there a chance QNX 6.6 will get a toolchain update at some point? Seems unlikely. http://stackoverflow.com/questions/34168433/am-i-able-to-use-c11-in-qnx Based on that, I get a tingling feeling that it's possible to update the toolchain but QNX deems that experimental, which is a probable turn-off for conservative customers. From jmcdonnell at blackberry.com Fri Mar 31 15:17:38 2017 From: jmcdonnell at blackberry.com (James McDonnell) Date: Fri, 31 Mar 2017 13:17:38 +0000 Subject: [Development] QNX 6.6 on Qt 5.10 In-Reply-To: References: <20170331121538.GA7480@orion> Message-ID: On 2017-03-31, 9:09 AM, "Development on behalf of Ville Voutilainen" wrote: >On 31 March 2017 at 15:48, Lars Knoll wrote: >> Hi Rafael, >> >> I¹d agree with you that it¹s too early to drop QNX 6.6, even though I >>understand that people would want to drop gcc 4.7. Is there a chance QNX >>6.6 will get a toolchain update at some point? > > >Seems unlikely. >http://stackoverflow.com/questions/34168433/am-i-able-to-use-c11-in-qnx >Based on that, I get a tingling feeling that it's possible to update >the toolchain but QNX deems that experimental, >which is a probable turn-off for conservative customers. An official GCC update for QNX 6.6.0 is very unlikely. From jmcdonnell at blackberry.com Fri Mar 31 15:25:44 2017 From: jmcdonnell at blackberry.com (James McDonnell) Date: Fri, 31 Mar 2017 13:25:44 +0000 Subject: [Development] QNX 6.6 on Qt 5.10 In-Reply-To: References: <20170331121538.GA7480@orion> Message-ID: On 2017-03-31, 9:17 AM, "Development on behalf of James McDonnell" wrote: > > >On 2017-03-31, 9:09 AM, "Development on behalf of Ville Voutilainen" >ville.voutilainen at gmail.com> wrote: > >>On 31 March 2017 at 15:48, Lars Knoll wrote: >>> Hi Rafael, >>> >>> I¹d agree with you that it¹s too early to drop QNX 6.6, even though I >>>understand that people would want to drop gcc 4.7. Is there a chance QNX >>>6.6 will get a toolchain update at some point? >> >> >>Seems unlikely. >>http://stackoverflow.com/questions/34168433/am-i-able-to-use-c11-in-qnx >>Based on that, I get a tingling feeling that it's possible to update >>the toolchain but QNX deems that experimental, >>which is a probable turn-off for conservative customers. > >An official GCC update for QNX 6.6.0 is very unlikely. Oh, and some of the problems are library problems; e.g., constexpr and initializer lists. A constexpr fix is even less likely than a GCC update. From alexander.blasche at qt.io Fri Mar 31 16:24:37 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Fri, 31 Mar 2017 14:24:37 +0000 Subject: [Development] supported compilers in 5.10? In-Reply-To: <65e27fa2-6ab7-636d-90e6-44a943e5c1a7@kdab.com> References: <201703301121.35735.marc.mutz@kdab.com> <65e27fa2-6ab7-636d-90e6-44a943e5c1a7@kdab.com> Message-ID: > -----Original Message---- > >> If we can drop MSVC 2013, too, we can start to use char16_t > >> unconditionlly, which will make QStringViewLiteral obsolete, as we can just > write u"foo" > >> everywhere. It will also simplify a lot of other code that currently > >> needs to fall back to wchar_t on Windows / MSVC 2013. > > > > It would certainly be nice not to have to worry about working around > > the various problems with MSVC 2013. > > I would favour to support only the latest two compilers (so 2017 and 2015), but > I've got the feeling it might be too early. People using MSVC move *slowly* to > the next compiler... I just looked through the download statistics. MSVC2015 takes about 30% of all windows downloads and the Visual Studio Tools have a similar ratio. It might change once we have a MSVC2017 packages but right now I must say no, dropping MSVC2015 is a no go for Qt 5.10. I can image we have a realistic chance for 5.11 though. -- Alex From marc.mutz at kdab.com Fri Mar 31 16:59:01 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 31 Mar 2017 16:59:01 +0200 Subject: [Development] supported compilers in 5.10? In-Reply-To: References: <201703301121.35735.marc.mutz@kdab.com> <65e27fa2-6ab7-636d-90e6-44a943e5c1a7@kdab.com> Message-ID: <201703311659.03442.marc.mutz@kdab.com> On Friday 31 March 2017 16:24:37 Alex Blasche wrote: > > -----Original Message---- > > > > >> If we can drop MSVC 2013, too, we can start to use char16_t > > >> unconditionlly, which will make QStringViewLiteral obsolete, as we can > > >> just > > > > write u"foo" > > > > >> everywhere. It will also simplify a lot of other code that currently > > >> needs to fall back to wchar_t on Windows / MSVC 2013. > > > > > > It would certainly be nice not to have to worry about working around > > > the various problems with MSVC 2013. > > > > I would favour to support only the latest two compilers (so 2017 and > > 2015), but I've got the feeling it might be too early. People using MSVC > > move *slowly* to the next compiler... > > I just looked through the download statistics. MSVC2015 takes about 30% of > all windows downloads and the Visual Studio Tools have a similar ratio. It > might change once we have a MSVC2017 packages but right now I must say no, > dropping MSVC2015 is a no go for Qt 5.10. > > I can image we have a realistic chance for 5.11 though. Are you talking about MSVC 2015 or 2013? -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From alexander.blasche at qt.io Fri Mar 31 16:55:04 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Fri, 31 Mar 2017 14:55:04 +0000 Subject: [Development] supported compilers in 5.10? In-Reply-To: References: <201703301121.35735.marc.mutz@kdab.com> <65e27fa2-6ab7-636d-90e6-44a943e5c1a7@kdab.com> Message-ID: > -----Original Message----- s/MSVC2015/MSVC2013/g > I just looked through the download statistics. MSVC2015 takes about 30% of all > windows downloads and the Visual Studio Tools have a similar ratio. It might > change once we have a MSVC2017 packages but right now I must say no, > dropping MSVC2015 is a no go for Qt 5.10. I am not sure why I mentioned MSVC2015 above. Please put MSVC2013 where I wrote MSVC2015 above. Thank you Kai for pointing this out. -- Alex From apoenitz at t-online.de Fri Mar 31 22:27:46 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 31 Mar 2017 22:27:46 +0200 Subject: [Development] QList In-Reply-To: <201703311056.54007.marc.mutz@kdab.com> References: <201703310943.12538.marc.mutz@kdab.com> <3776251490946198@web15m.yandex.ru> <201703311056.54007.marc.mutz@kdab.com> Message-ID: <20170331202746.GA3405@klara.mpi.htwm.de> On Fri, Mar 31, 2017 at 10:56:53AM +0200, Marc Mutz wrote: > On Friday 31 March 2017 09:43:18 Konstantin Tokarev wrote: > > 31.03.2017, 10:38, "Marc Mutz" : > [...] > > > [1] even better than Qt's, these days, since cppreference.com > > > clearly shows what's available in which C++ version while Qt hides > > > all but the latest documentation, which only describes the current > > > state of affairs. > > > > Each Qt release is shipped with documentation. > > That doesn't help if you develop software that's supposed to be > compatible with multiple Qt versions. Even if you install all Qt > releases, the fact that you have separate documents per version makes > finding past changes very hard. > > > Also, there is \since. > > But no \until. I try to put this in the docs, and sometimes I > succeeded, but I've also been -1ed for trying already. Funnily enough I never caught you trying that. But sure, removing convenience from Qt by itself is -1-worthy, as is trying to set up infrastructure to allow that. > Thanks, You are welcome. Andre'