Re: [Development] Wishes for C++ standard or compilers

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/ qRe

Re: [Development] QList

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; > > > [

Re: [Development] QList

>>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 th

Re: [Development] QList

> 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

Re: [Development] applications dropping keyboard input

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 a

Re: [Development] QList

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 KD

Re: [Development] QList

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 > >>> chang

Re: [Development] Wishes for C++ standard or compilers

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 be

Re: [Development] Who's responsible for 3rdparty these days (QTBUG-59586)?

> -Original Message- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Thiago Macieira > Sent: Sunday, March 19, 2017 8:01 PM > To: development@qt-project.org > Subject: [Development] Who's responsible for 3rdparty these days (QTBUG- > 59586)?

Re: [Development] Wishes for C++ standard or compilers

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 QtScri

Re: [Development] Wishes for C++ standard or compilers

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-proc

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

Re: [Development] QList

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

Re: [Development] QList

>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

Re: [Development] Need advise on acceptable timeouts for autotests

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/tas

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: > >

Re: [Development] QList

>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 us

Re: [Development] QList

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 Q

Re: [Development] QList

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, sin

Re: [Development] QList

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 in

Re: [Development] QList

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 ru

Re: [Development] QList

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

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

Re: [Development] QList

> 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

Re: [Development] Who's responsible for 3rdparty these days (QTBUG-59586)?

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 thi

Re: [Development] QList

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 > f

Re: [Development] QList

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 prett

Re: [Development] QList

> 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

Re: [Development] QList

-Original Message- From: Development [mailto:development-bounces+scott=towel42@qt-project.org] On Behalf Of Konrad Rosenbaum Sent: Monday, March 20, 2017 07:57 To: development@qt-project.org Subject: Re: [Development] QList On Mon, March 20, 2017 15:19, Marc Mutz wrote: > Well, seri

Re: [Development] QList

On Monday 20 March 2017 16:40:07 Scott Aron Bloom wrote: > -Original Message- > From: Development > [mailto:development-bounces+scott=towel42@qt-project.org] On Behalf Of > Konrad Rosenbaum Sent: Monday, March 20, 2017 07:57 > To: development@qt-project.org > Subject: Re: [Development]

Re: [Development] QList

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

Re: [Development] QList

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 c

Re: [Development] QList

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 s

Re: [Development] QList

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 look

Re: [Development] QList

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

Re: [Development] QList

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 tak

Re: [Development] Use of std::function in Qt API

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

Re: [Development] QList

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 >>

Re: [Development] Use of std::function in Qt API

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

Re: [Development] QList

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 plat

Re: [Development] QList

> 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

Re: [Development] Wishes for C++ standard or compilers

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 cont

Re: [Development] QList

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 b

Re: [Development] QList

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 ___ Developm

Re: [Development] QList

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

Re: [Development] QList

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. Wha

Re: [Development] QList

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 n

Re: [Development] QList

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

Re: [Development] QList

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, release

Re: [Development] QList

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 k