> 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
> 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 fut
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
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 t
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 =
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 unders
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.
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 m
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
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 wha
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). O
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 (unlik
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 cons
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
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
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
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
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 r
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 coun
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
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
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
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 QLi
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
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
>> 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 +01
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 stron
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 QL
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 f
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 probabl
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;
31 matches
Mail list logo
