Re: [Development] syncqt.pl in C++

> 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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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 =

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

[Development] Wishes for C++ standard or compilers

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

Re: [Development] QList

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

[Development] applications dropping keyboard input

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

Re: [Development] QList

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

[Development] QList

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;