Re: [Development] QList for Qt 6

[Matthew Woehlke]

On 12/06/2019 18.14, Matthew Woehlke wrote:
> On 22/05/2019 12.41, Konstantin Tokarev wrote:
>> In the latter QList can be replaced with 
>> std::vector> or QVector>
>
> No, it can't. `QList` has value semantics w.r.t. `T`. Your
> "alternatives" have pointer semantics.

And, to be clear... while having to write `*` and `->` is annoying, it
gets worse:

  good_list.append(value);

  // Never mind that we can't 'append'...
  bad_list.emplace_back(new /* AIEE! */ value_t{value});
  bad_list.emplace_back(std::make_unique(value));

...and worse:

  auto evil = std::move(bad_list[i]);
  bad_list[i]->frob();

A `QList` *always* has a value at a valid index. Your proposed
"alternatives" don't have that guarantee.

A `vector>` is simply **NOT** a replacement for
`QArrayList`. Period.

-- 
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Matthew Woehlke]

(Sorry for not chiming in earlier, this was hidden wy at the top of
my spool where I didn't notice there were unread messages.)

On 22/05/2019 09.49, Lars Knoll wrote:
> Let’s conclude the topic of QList. I do see the concern about silent
> source breakages. Here’s what we’ll (I’ll) do then for Qt 6:
> 
> 1. Rename QList to QArrayList and make QList an alias to QArrayList

+lots. I have (grudgingly) been slowly moving toward using QVector more,
but I still think there are legitimate cases when it makes sense to
avoid copies-during-resizing. And, of course, there are times when one
needs reference stability. I don't want to lose that container.

It would be helpful to have a QArrayList that *always* uses indirect
storage, and to have a clazy check for use of QArrayList where
QVector is almost certainly a better choice (e.g. at least all cases
where QList would not use indirect storage, and possibly with some
heuristic for "small" and movable types).

> 2. Move QStringList and QByteArrayList over to inherit from QVector (that 
> should be source compatible)

+1.

> 7. Make the implementation of QArrayList fully inline and deprecate the class.

-lots, as long as Qt has container classes. (I still want an STL version
of QArrayList, also...)

However, QList should be deprecated.

On 22/05/2019 12.41, Konstantin Tokarev wrote:
> In the latter QList can be replaced with 
> std::vector> or QVector>
No, it can't. `QList` has value semantics w.r.t. `T`. Your
"alternatives" have pointer semantics.

-- 
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Scott Bloom]

I'm a bit late to this game, but ...
> I don’t see why you’d want to remove the switch for Qt 6. 
> It would be a porting help for application developers.

Application developers will not build their own Qt, but rely on the QList with 
the switch their Qt and Qt-using 3rd party libraries are built with.

And how does it work if different 3rdparty qt libraries requires the switch 
differently?

/Sune
 - Qt, KDE and Debian guy at night. Qt & c++ freelancer by day.

___

I can tell you from m Qt3 -> Qt4 transition, with a similar switch (to enable 
Qt3 functions that were killed off)

We did the following.. Our release, was built with the Qt3to4 library and 
switches enabled.

However, our developer builds had the switch turned off, so we didn’t introduce 
new code using the old API.

Scott
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Sune Vuorela]

On 2019-05-23, Lars Knoll  wrote:

I'm a bit late to this game, but ...
> I don’t see why you’d want to remove the switch for Qt 6. 
> It would be a porting help for application developers.

Application developers will not build their own Qt, but rely on the
QList with the switch their Qt and Qt-using 3rd party libraries are
built with.

And how does it work if different 3rdparty qt libraries requires the
switch differently?

/Sune
 - Qt, KDE and Debian guy at night. Qt & c++ freelancer by day.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Thiago Macieira]

On Wednesday, 29 May 2019 02:26:57 PDT Lars Knoll wrote:
> > On 28 May 2019, at 17:17, Thiago Macieira 
> > wrote:
 
> > On Monday, 27 May 2019 04:51:35 PDT Eike Ziller wrote:
> > 
> >>> * QVector for Qt 6 will most likely be updated with the changes Thiago
> >>> has
> >>> waiting since quite some years
> >> 
> >> What is the summary for these?
> > 
> > 
> > The long story short is that the begin pointer and size members move from
> > the  d pointer to the actual object. The slightly longer story is that
> > it's implemented using QArrayDataPointer and the supposedly
> > exception-safe, tag- dispatched operations in QArrayDataOps that João
> > wrote 7-8 years ago.
> 
> How important is exception safety? I’m rather unsure whether that’s
> required.

It's not. The point is that it's implemented. And the tag dispatching is 
actually an improvement over our current code, since it produces much more 
optimised code for the particulars of each T.

> > I also introduced a QGenericArray class that QVector derives from and
> > QList  could have, but doesn't look like it will be necessary for Qt 6.
> 
> 
> Weren’t you also thinking about using the same data structure for QByteArray
> and QString?

QArrayDataPointer yes. QGenericArray really is QVector, except for the methods 
that return QVector references.

But I never got either QByteArray or QString to use QADP. That's the point 
where I ran out of time 7 years ago.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lars Knoll]

> On 28 May 2019, at 17:17, Thiago Macieira  wrote:
> 
> On Monday, 27 May 2019 04:51:35 PDT Eike Ziller wrote:
>>> * QVector for Qt 6 will most likely be updated with the changes Thiago has
>>> waiting since quite some years
>> What is the summary for these?
> 
> The long story short is that the begin pointer and size members move from the 
> d pointer to the actual object. The slightly longer story is that it's 
> implemented using QArrayDataPointer and the supposedly exception-safe, tag-
> dispatched operations in QArrayDataOps that João wrote 7-8 years ago.

How important is exception safety? I’m rather unsure whether that’s required.
> 
> I also introduced a QGenericArray class that QVector derives from and QList 
> could have, but doesn't look like it will be necessary for Qt 6.

Weren’t you also thinking about using the same data structure for QByteArray 
and QString?

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Thiago Macieira]

On Monday, 27 May 2019 04:51:35 PDT Eike Ziller wrote:
> > * QVector for Qt 6 will most likely be updated with the changes Thiago has
> > waiting since quite some years
> What is the summary for these?

The long story short is that the begin pointer and size members move from the 
d pointer to the actual object. The slightly longer story is that it's 
implemented using QArrayDataPointer and the supposedly exception-safe, tag-
dispatched operations in QArrayDataOps that João wrote 7-8 years ago.

I also introduced a QGenericArray class that QVector derives from and QList 
could have, but doesn't look like it will be necessary for Qt 6.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lars Knoll]

On 27 May 2019, at 13:51, Eike Ziller 
mailto:eike.zil...@qt.io>> wrote:



On 27. May 2019, at 12:49, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:

On 27 May 2019, at 11:37, Giuseppe D'Angelo 
mailto:giuseppe.dang...@kdab.com>> wrote:

Il 27/05/19 10:24, Simon Hausmann ha scritto:
Hi,
I’m very much in favor of having QList be an alias for QVector and try it out, 
in qt5, with creator and KDE.

Could someone please summarize where we are inside this thread? Now I'm 
completely lost…

My summary would be as follows:

* We rename QList to QArrayList
* We can still discuss whether it should rather be Qt5::QList
* QStringList and QBAList will be implemented using QVector
* QList becomes an alias to QVector in wip/qt6 (for now at least)
* We delay the decision on what QList will be in Qt 6 for a little while
* QVector for Qt 6 will most likely be updated with the changes Thiago has 
waiting since quite some years

What is the summary for these?

Thiago?


* To be able to reach a decision:
* we test some Qt libs and apps with QList being an alias to QVector
* We know that the only source incompatibility is the stability of references

At least the following are source incompatibilities currently (though easily 
noticeable because they generate compile errors):

- QVector doesn’t have to/fromSet, to/fromStdList or (obviously) to/fromVector

See https://codereview.qt-project.org/c/qt/qtbase/+/260813 . To/fromVector will 
be added as deprecated methods in Qt 6.

- QVector requires the value type to be default constructible

Already fixed , see https://codereview.qt-project.org/c/qt/qtbase/+/242197

Cheers,
Lars


* If it turns out that most of Qt and (maybe also KDE) run without problems 
with QList = QVector, we should IMO go down that route.
* The reason is that aliasing those classes will resolve many other problems we 
could otherwise run into

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

--
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.zil...@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

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Eike Ziller]

> On 27. May 2019, at 12:49, Lars Knoll  wrote:
> 
>> On 27 May 2019, at 11:37, Giuseppe D'Angelo  
>> wrote:
>> 
>> Il 27/05/19 10:24, Simon Hausmann ha scritto:
>>> Hi,
>>> I’m very much in favor of having QList be an alias for QVector and try it 
>>> out, in qt5, with creator and KDE.
>> 
>> Could someone please summarize where we are inside this thread? Now I'm 
>> completely lost…
> 
> My summary would be as follows:
> 
> * We rename QList to QArrayList
>   * We can still discuss whether it should rather be Qt5::QList
> * QStringList and QBAList will be implemented using QVector
> * QList becomes an alias to QVector in wip/qt6 (for now at least)
> * We delay the decision on what QList will be in Qt 6 for a little while
> * QVector for Qt 6 will most likely be updated with the changes Thiago has 
> waiting since quite some years

What is the summary for these?

> * To be able to reach a decision:
>   * we test some Qt libs and apps with QList being an alias to QVector
>   * We know that the only source incompatibility is the stability of 
> references

At least the following are source incompatibilities currently (though easily 
noticeable because they generate compile errors):

- QVector doesn’t have to/fromSet, to/fromStdList or (obviously) to/fromVector
- QVector requires the value type to be default constructible 

>   * If it turns out that most of Qt and (maybe also KDE) run without 
> problems with QList = QVector, we should IMO go down that route.
>   * The reason is that aliasing those classes will resolve many other 
> problems we could otherwise run into
> 
> Cheers,
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.zil...@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

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lars Knoll]

> On 27 May 2019, at 11:37, Giuseppe D'Angelo  wrote:
> 
> Il 27/05/19 10:24, Simon Hausmann ha scritto:
>> Hi,
>> I’m very much in favor of having QList be an alias for QVector and try it 
>> out, in qt5, with creator and KDE.
> 
> Could someone please summarize where we are inside this thread? Now I'm 
> completely lost…

My summary would be as follows:

* We rename QList to QArrayList
* We can still discuss whether it should rather be Qt5::QList
* QStringList and QBAList will be implemented using QVector
* QList becomes an alias to QVector in wip/qt6 (for now at least)
* We delay the decision on what QList will be in Qt 6 for a little while
* QVector for Qt 6 will most likely be updated with the changes Thiago has 
waiting since quite some years
* To be able to reach a decision:
* we test some Qt libs and apps with QList being an alias to QVector
* We know that the only source incompatibility is the stability of 
references
* If it turns out that most of Qt and (maybe also KDE) run without 
problems with QList = QVector, we should IMO go down that route.
* The reason is that aliasing those classes will resolve many other 
problems we could otherwise run into

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Giuseppe D'Angelo via Development]

Il 27/05/19 10:24, Simon Hausmann ha scritto:

Hi,

I’m very much in favor of having QList be an alias for QVector and try it out, 
in qt5, with creator and KDE.


Could someone please summarize where we are inside this thread? Now I'm 
completely lost...


Thanks,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Simon Hausmann]

Hi,

I’m very much in favor of having QList be an alias for QVector and try it out, 
in qt5, with creator and KDE.


Simon

On 27. May 2019, at 10:12, Lars Knoll  wrote:

>> On 25 May 2019, at 00:37, Giuseppe D'Angelo via Development 
>>  wrote:
>> 
>> Il 24/05/19 18:16, Uwe Rathmann ha scritto:
 We're talking about code that users should_stop_  using anyhow,
 and port away from it, right?
>>> Please also consider the situation of 3rd party libraries ( like Qwt ),
>>> that have to support Qt5/Qt6 from the same code base - probably for many
>>> years after Qt6 has been released.
>>> Currently Qwt supports all Qt version >= Qt 4.4. Qwt 5.x did even
>>> support Qt3/Qt4 from the same code base, what was a nightmare as you can
>>> imagine.
>>> In my daily work project we also have a set of core libraries, that run
>>> on old hardware with Qt4/QWS and on more recent projects with Qt5.
>> 
>> This is yet another argument in favour of "don't touch QList": codebases 
>> that need compatibility.
> 
> Having QList an alias to QVector would solve almost all of those problems 
> (except for the fear that now unstable references might break some code).
> 
> I’d say we now check on some larger code bases (Qt, Creator and maybe some 
> parts of KDE), how replacing QList with QVector works out in practice. And do 
> a decision after that.
> 
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lars Knoll]

> On 25 May 2019, at 00:37, Giuseppe D'Angelo via Development 
>  wrote:
> 
> Il 24/05/19 18:16, Uwe Rathmann ha scritto:
>>> We're talking about code that users should_stop_  using anyhow,
>>> and port away from it, right?
>> Please also consider the situation of 3rd party libraries ( like Qwt ),
>> that have to support Qt5/Qt6 from the same code base - probably for many
>> years after Qt6 has been released.
>> Currently Qwt supports all Qt version >= Qt 4.4. Qwt 5.x did even
>> support Qt3/Qt4 from the same code base, what was a nightmare as you can
>> imagine.
>> In my daily work project we also have a set of core libraries, that run
>> on old hardware with Qt4/QWS and on more recent projects with Qt5.
> 
> This is yet another argument in favour of "don't touch QList": codebases that 
> need compatibility.

Having QList an alias to QVector would solve almost all of those problems 
(except for the fear that now unstable references might break some code).

I’d say we now check on some larger code bases (Qt, Creator and maybe some 
parts of KDE), how replacing QList with QVector works out in practice. And do a 
decision after that.

Lars

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Thiago Macieira]

On Friday, 24 May 2019 05:09:30 PDT Mutz, Marc via Development wrote:
> 1. Make QVector slower for every user (because of the extra memory load
> in calculating begin())

Nope. QVector, QString and QByteArray carry their begin pointer in the object 
itself. So there's no indirect load *and* it supports the takeFirst() 
optimisation.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lisandro Damián Nicanor Pérez Meyer]

Hi Marco!

On Fri, 24 May 2019 at 18:34, Marco Bubke  wrote:
>
> Maybe flatpak is the way to go? There could be two runtimes. Personally I use 
> more and more flatpaks because I get up-to-date packages provided by the 
> developers.

With my maintainer hat on: no, flatpak is not the way to go for
distributions. You might prefer them for your use cases, but
definitely not for a distro.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Giuseppe D'Angelo via Development]

Il 24/05/19 18:16, Uwe Rathmann ha scritto:

We're talking about code that users should_stop_  using anyhow,
and port away from it, right?

Please also consider the situation of 3rd party libraries ( like Qwt ),
that have to support Qt5/Qt6 from the same code base - probably for many
years after Qt6 has been released.

Currently Qwt supports all Qt version >= Qt 4.4. Qwt 5.x did even
support Qt3/Qt4 from the same code base, what was a nightmare as you can
imagine.

In my daily work project we also have a set of core libraries, that run
on old hardware with Qt4/QWS and on more recent projects with Qt5.


This is yet another argument in favour of "don't touch QList": codebases 
that need compatibility.



--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Marco Bubke]

Maybe flatpak is the way to go? There could be two runtimes. Personally I use 
more and more flatpaks because I get up-to-date packages provided by the 
developers.

On May 24, 2019 19:59:52 Lisandro Damián Nicanor Pérez Meyer 
 wrote:

> Hi!
>
> On Mon, 20 May 2019 at 10:53, Lars Knoll  wrote:
> [snip]
>> I’m not proposing to make QList inherit QVector. Actually, I’m making it an 
>> alias to QVector. See https://codereview.qt-project.org/c/qt/qtbase/+/242692 
>> .
>>
>>
>> With that, one option could be to make the alias dependent on a compile time 
>> setting for the application code (ie. have a simple define whether we do
>>
>>
>> using QList = QVector
>>
>>
>> Or
>>
>>
>> using QList = Qt5Support::QList
>
> That would actually be painful for distros. Once we take either route
> we can't go back without breaking ABI. And we will possibly be
> choosing different things in each distro, which makes it even worst.
> Example: qreal in Qt5.
>
> I really think Marc Mutz's approach would be more sensible in this case.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Mon, 20 May 2019 at 10:53, Lars Knoll  wrote:
[snip]
> I’m not proposing to make QList inherit QVector. Actually, I’m making it an 
> alias to QVector. See https://codereview.qt-project.org/c/qt/qtbase/+/242692 .
>
> With that, one option could be to make the alias dependent on a compile time 
> setting for the application code (ie. have a simple define whether we do
>
> using QList = QVector
>
> Or
>
> using QList = Qt5Support::QList

That would actually be painful for distros. Once we take either route
we can't go back without breaking ABI. And we will possibly be
choosing different things in each distro, which makes it even worst.
Example: qreal in Qt5.

I really think Marc Mutz's approach would be more sensible in this case.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Uwe Rathmann]

On 5/24/19 2:30 PM, Giuseppe D'Angelo via Development wrote:

We're talking about code that users should _stop_ using anyhow, 
and port away from it, right?


Please also consider the situation of 3rd party libraries ( like Qwt ), 
that have to support Qt5/Qt6 from the same code base - probably for many 
years after Qt6 has been released.


Currently Qwt supports all Qt version >= Qt 4.4. Qwt 5.x did even 
support Qt3/Qt4 from the same code base, what was a nightmare as you can 
imagine.


In my daily work project we also have a set of core libraries, that run 
on old hardware with Qt4/QWS and on more recent projects with Qt5.


ciao,
Uwe


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Giuseppe D'Angelo via Development]

Il 24/05/19 14:09, Mutz, Marc via Development ha scritto:

2. Keep QList as-is. It cannot be an alias to QVector/QArrayList, nor
can it be implemented in terms of either (only at the d-pointer level)

Is it worth the cost? I don't know.


I'm still in favour at keeping QList as-is and paying the conversion 
price. We're talking about code that users should _stop_ using anyhow, 
and port away from it, right? I.e. Q5List in Qt 6.0 is going to emit 
deprecation warnings?


(And the port away could be as simple as a s/QList/QVector/ if the 
codebase is not using any of the QList "fancy" features.)


My 2 c,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lars Knoll]

> On 24 May 2019, at 14:09, Mutz, Marc via Development 
>  wrote:
> 
> On 2019-05-24 11:03, Lars Knoll wrote:
> [...]
>> You conveniently didn’t quote the first part of my answer. I didn’t
>> say that. I said I really want to ensure that we get a zero copy
>> conversion between QList and QVector where this doesn’t imply
>> (possible) incorrectness in the code. That’s the case for all types
>> that are smaller than a pointer and movable.
> 
> Ok, I'm sorry if I misinterpreted your mail. All too easy with text :)
> 
> So, what's the conclusion from that experiment? We can't make QList switch 
> between QArrayList and QVector based on properties of the type, because that 
> breaks declaring QList. 'Switch' here means anything from 
> a selecting template alias to QList inheriting or aggregating QArrayList or 
> QVector, based on the template argument.

That’s basically the conclusion.
> 
> So the only solution, if you want zero-copy conversion between QVector and 
> Q5List-excl-IndirectLayout is to keep Q5List, remove the padding, and add the 
> begin offset optimization to QVector. Then a reinterpret_cast of the 
> d-pointer should be enough.
> 
> To summarize: zero-cost conversion between QList and QVector means:
> 
> 1. Make QVector slower for every user (because of the extra memory load in 
> calculating begin())

Possibly, but I think a lot of this depends on how QVector looks in Qt 6. 
Thiago had a series of patches for that, that we’ll need to take into account. 
I vaguely recall that he once mentioned that he could do the prepend 
optimisation without additional cost.

> 2. Keep QList as-is. It cannot be an alias to QVector/QArrayList, nor can it 
> be implemented in terms of either (only at the d-pointer level)

It would require changes to QList’s implementation, but those should be 
relatively straightforward.
> 
> Is it worth the cost? I don't know.

I at least don’t want to do this now, as long as I know QVector might be 
changing as well (because operations on the d-pointer level could mean that the 
code would need to be changed.

So to adjust plans, I’ll leave it with the renaming of QList to QArrayList for 
now, and make QList an alias to QVector while we’re working on Qt 6. Once we 
know QVector has it’s final form, we can then revisit QList.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Mutz, Marc via Development]

On 2019-05-24 11:03, Lars Knoll wrote:
[...]

You conveniently didn’t quote the first part of my answer. I didn’t
say that. I said I really want to ensure that we get a zero copy
conversion between QList and QVector where this doesn’t imply
(possible) incorrectness in the code. That’s the case for all types
that are smaller than a pointer and movable.


Ok, I'm sorry if I misinterpreted your mail. All too easy with text :)

So, what's the conclusion from that experiment? We can't make QList 
switch between QArrayList and QVector based on properties of the type, 
because that breaks declaring QList. 'Switch' here 
means anything from a selecting template alias to QList inheriting or 
aggregating QArrayList or QVector, based on the template argument.


So the only solution, if you want zero-copy conversion between QVector 
and Q5List-excl-IndirectLayout is to keep Q5List, remove the padding, 
and add the begin offset optimization to QVector. Then a 
reinterpret_cast of the d-pointer should be enough.


To summarize: zero-cost conversion between QList and QVector means:

1. Make QVector slower for every user (because of the extra memory load 
in calculating begin())
2. Keep QList as-is. It cannot be an alias to QVector/QArrayList, nor 
can it be implemented in terms of either (only at the d-pointer level)


Is it worth the cost? I don't know.

Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Konstantin Tokarev]

24.05.2019, 14:27, "Konstantin Tokarev" :
> Actually, clazy provides related checks "inefficient-qlist". I think 
> following plan can work:
>
> 1. Implement opposite "replace-efficient-qlist-to-qvector" check in clazy 
> which finds QList
> where sizeof(T) <= sizeof(void*) and T is movable, and allows automatic 
> replacement with QVector
>
> 2. Apply this transformation to all public and private Qt APIs, and refrain 
> from QList replacements
> in places which are not sanctioned by tool.

2a. Replace remaining uses of QList in public and private APIs with 
typedefs/aliases, like
QList -> QSomethingList

>
> 3. Implement clazy check "inefficient-qvector-insert" which warns when 
> prepend/push_front and
> insert into middle are used with QVector.
>
> Algorithm of porting to Qt 6 could be:
>
> 1. Run inefficient-qvector-insert over code base and store results
> 2. Apply replace-efficient-qlist-to-qvector to whole code base
> 3. Run inefficient-qvector-insert again and make a diff with step 1, and 
> suggest user to check
> these cases carefully for possible reference issues and performance 
> regressions
>
> Results:
> 1. Do a big chunk of worldwide QList elemination without compatibility hacks 
> and with relatively
> low risk
> 2. Users should finally get the message that QList is not the go-to container 
> preferred in most cases.
>
> Porting other part of QList usages can be delayed to Qt7.
-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

One change that is relatively painless but will set things for the later
reintroduction of QList as a proper class would be with Qt6 force rename
QList instances to Qt5SupportList.
Note that if it's done at the same time as removal of QList from Qt
interfaces entirely, then it's a simple pass of batch rename and then
replugging into Qt interfaces with actual correct classes.

The benefits of this are:
1) QList is officially deprecated and discouraged by its very name
2) Usercode that doesn't interface with Qt systems needs not be changed
outside the rename which can be fully automatic instead of on case by case
instance.
3) Come Qt7 QList can be reintroduced with an entirely different
implementation (because losing that name forever seems excessive)

On Fri, May 24, 2019 at 2:23 PM Konstantin Tokarev 
wrote:

>
>
> 24.05.2019, 13:32, "Konstantin Tokarev" :
> > 24.05.2019, 13:06, "NIkolai Marchenko" :
> >>  All of the back and forth on this issue recently and over the years
> really make want to ask this question:
> >>
> >>  Is the promise of SC worth all the potenital pitfalls? There seems to
> be no end to the discussion with every solution requiriring hair rising
> compromises.
> >>  Is it _really_ that impossible to just remove QLIst entirely and force
> user to choose form a range of classes each tailored for the specific
> scenario that QList tried to cover?
> >>
> >>  As it is, it seems like we're rapidly heading to a nightmarish
> scenario worse than any SC breakage, where users will have to looks for
> problems in a perfectly compiling code.
> >>
> >>  Is the gordian knot of full SC really possible to unravel or is it
> time to axe it?
> >
> > If we remove QList, users with thousands of occurrences of QList in code
> base will likely do
> > mechanical replacement s/QList/QVector/g, or use the same template alias
> as it was proposed
> > earlier in this thread.
> >
> > To axe this problem, automatic clang-based porting tool is needed. Such
> tool would analyze
> > context and do a replacement of QList to QVector in places where it's
> least likely to introduce
> > issues, e.g. where QList is used with movable types which are not larger
> than void*, or where
> > QList is used as a local variable and it's possible to prove that
> references or iterators pointing
> > to this local QList members are never used after QList modification.
> >
> > If users end up with little manual work, it's more likely that they will
> carefully analyze all remaining
> > cases.
>
> Actually, clazy provides related checks "inefficient-qlist". I think
> following plan can work:
>
> 1. Implement opposite "replace-efficient-qlist-to-qvector" check in clazy
> which finds QList
> where sizeof(T) <= sizeof(void*) and T is movable, and allows automatic
> replacement with QVector
>
> 2. Apply this transformation to all public and private Qt APIs, and
> refrain from QList replacements
> in places which are not sanctioned by tool.
>
> 3. Implement clazy check "inefficient-qvector-insert" which warns when
> prepend/push_front and
> insert into middle are used with QVector.
>
> Algorithm of porting to Qt 6 could be:
>
> 1. Run inefficient-qvector-insert over code base and store results
> 2. Apply replace-efficient-qlist-to-qvector to whole code base
> 3. Run inefficient-qvector-insert again and make a diff with step 1, and
> suggest user to check
> these cases carefully for possible reference issues and performance
> regressions
>
> Results:
> 1. Do a big chunk of worldwide QList elemination without compatibility
> hacks and with relatively
> low risk
> 2. Users should finally get the message that QList is not the go-to
> container preferred in most cases.
>
> Porting other part of QList usages can be delayed to Qt7.
>
> --
> Regards,
> Konstantin
>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Konstantin Tokarev]

24.05.2019, 13:32, "Konstantin Tokarev" :
> 24.05.2019, 13:06, "NIkolai Marchenko" :
>>  All of the back and forth on this issue recently and over the years really 
>> make want to ask this question:
>>
>>  Is the promise of SC worth all the potenital pitfalls? There seems to be no 
>> end to the discussion with every solution requiriring hair rising 
>> compromises.
>>  Is it _really_ that impossible to just remove QLIst entirely and force user 
>> to choose form a range of classes each tailored for the specific scenario 
>> that QList tried to cover?
>>
>>  As it is, it seems like we're rapidly heading to a nightmarish scenario 
>> worse than any SC breakage, where users will have to looks for problems in a 
>> perfectly compiling code.
>>
>>  Is the gordian knot of full SC really possible to unravel or is it time to 
>> axe it?
>
> If we remove QList, users with thousands of occurrences of QList in code base 
> will likely do
> mechanical replacement s/QList/QVector/g, or use the same template alias as 
> it was proposed
> earlier in this thread.
>
> To axe this problem, automatic clang-based porting tool is needed. Such tool 
> would analyze
> context and do a replacement of QList to QVector in places where it's least 
> likely to introduce
> issues, e.g. where QList is used with movable types which are not larger than 
> void*, or where
> QList is used as a local variable and it's possible to prove that references 
> or iterators pointing
> to this local QList members are never used after QList modification.
>
> If users end up with little manual work, it's more likely that they will 
> carefully analyze all remaining
> cases.

Actually, clazy provides related checks "inefficient-qlist". I think following 
plan can work:

1. Implement opposite "replace-efficient-qlist-to-qvector" check in clazy which 
finds QList
where sizeof(T) <= sizeof(void*) and T is movable, and allows automatic 
replacement with QVector

2. Apply this transformation to all public and private Qt APIs, and refrain 
from QList replacements
in places which are not sanctioned by tool. 

3. Implement clazy check "inefficient-qvector-insert" which warns when 
prepend/push_front and
insert into middle are used with QVector.

Algorithm of porting to Qt 6 could be:

1. Run inefficient-qvector-insert over code base and store results
2. Apply replace-efficient-qlist-to-qvector to whole code base
3. Run inefficient-qvector-insert again and make a diff with step 1, and 
suggest user to check
these cases carefully for possible reference issues and performance regressions

Results:
1. Do a big chunk of worldwide QList elemination without compatibility hacks 
and with relatively
low risk
2. Users should finally get the message that QList is not the go-to container 
preferred in most cases.

Porting other part of QList usages can be delayed to Qt7.

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Edward Welbourne]

NIkolai Marchenko (24 May 2019 12:03) asked
> Is the gordian knot of full SC really possible to unravel or is it time to 
> axe it?

Or at least, for this one case, recognise that a SC break is better than
the alternatives and, since this is the Qt6 transition where we don't
promise not to make SC breaks, bite the bullet.  If we recommend
changing QList to QVector (or auto, where applicable) and give
guidelines on what kinds of code patterns to watch out for, where some
other change may be needed, there's a straightforward task with clear
guidance on where to expect to complications.  Any client code whose
maintainers do code review will then have one big sweeping change and
then put QList behind them.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Konstantin Tokarev]

24.05.2019, 13:06, "NIkolai Marchenko" :
> All of the back and forth on this issue recently and over the years really 
> make want to ask this question:
>
> Is the promise of SC worth all the potenital pitfalls? There seems to be no 
> end to the discussion with every solution requiriring hair rising compromises.
> Is it _really_ that impossible to just remove QLIst entirely and force user 
> to choose form a range of classes each tailored for the specific scenario 
> that QList tried to cover?
>
> As it is, it seems like we're rapidly heading to a nightmarish scenario worse 
> than any SC breakage, where users will have to looks for problems in a 
> perfectly compiling code.
>
> Is the gordian knot of full SC really possible to unravel or is it time to 
> axe it?

If we remove QList, users with thousands of occurrences of QList in code base 
will likely do
mechanical replacement s/QList/QVector/g, or use the same template alias as it 
was proposed
earlier in this thread.

To axe this problem, automatic clang-based porting tool is needed. Such tool 
would analyze
context and do a replacement of QList to QVector in places where it's least 
likely to introduce
issues, e.g. where QList is used with movable types which are not larger than 
void*, or where
QList is used as a local variable and it's possible to prove that references or 
iterators pointing
to this local QList members are never used after QList modification.

If users end up with little manual work, it's more likely that they will 
carefully analyze all remaining
cases.

If we are not ready to provide such tool before 6.0 release, IMO it would be 
better to avoid touching
QList at all, and instead concentrate on removing QList from public APIs. In 
this case users can
start porting their code from places where conversions between QList and 
QVector introduce visible
impact on performance, and start writing new code with QVector.


-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

All of the back and forth on this issue recently and over the years really
make want to ask this question:

Is the promise of SC worth all the potenital pitfalls? There seems to be no
end to the discussion with every solution requiriring hair rising
compromises.
Is it _really_ that impossible to just remove QLIst entirely and force user
to choose form a range of classes each tailored for the specific scenario
that QList tried to cover?

As it is, it seems like we're rapidly heading to a nightmarish scenario
worse than any SC breakage, where users will have to looks for problems in
a perfectly compiling code.

Is the gordian knot of full SC really possible to unravel or is it time to
axe it?



On Fri, May 24, 2019 at 12:04 PM Lars Knoll  wrote:

> > On 24 May 2019, at 10:19, Mutz, Marc via Development <
> development@qt-project.org> wrote:
> >
> > On 2019-05-24 09:35, Lars Knoll wrote:
> >>> On 23 May 2019, at 13:26, Mutz, Marc via Development <
> development@qt-project.org> wrote:
> > [...]
> >>> You said that QList should vanish from Qt API. So we don't care. We'll
> have that switch to make QList _be_ QVector for ese of porting, but as a
> template alias. There's your zero-copy conversion :) That leaves users. And
> I repeat: I'd leave QList alone (as QArrayList, possibly with always
> IndirectLayout), and just have implicit deprecated conversions between
> QArrayList and QVector. You shouldn't care about performance of unported
> code: It's easy to target both Qt 5 and Qt 6 if you use auto for receiving
> from Qt API. For sending to Qt API, it's a bit more tricky. You need to
> ifdef or live with the implicit conversion in a Qt 6 build, but it's not
> something that we should optimize for. Really. Don’t.
> >> Sorry, but no. Larger performance regressions that are not really
> >> visible/cought at compile time can be as large a headache to our users
> >> as the non stable references to data in the container.
> >
> > Sorry, you're comparing apples and oranges, iow: a performance issue
> with a correctness issue. You cannot weigh them against each other. We need
> to ensure that user code stays correct _first_, fast _second_. The first
> rule of optimisation: Don't do it. The second rule: Don't do it _yet_.
> Write correct code first, optimize later. You can't turn that around. It'd
> send a catastrophic signal to Qt users.
>
> Yes, both are different things. But for a user moving from Qt 5 to Qt 6,
> it mainly matters how he is affected by this.
>
> And there might be quite a few people who will never hit the problem with
> stability of references (because storing a reference to a member of the
> list is not that common), but they will be seeing performance issues
> because of the implicit (and hidden) conversion.
>
> >
> > Here's how I see it: performance problems show up in testing, and are
> easily identified by a profiler, a tool that is available on every platform
> and everyone knows how to use it. Stability of references problems are
> found, if at all, by memory sanitizers, something that much less people
> will be familiar with, and, crucially, might hide in less-well tested code.
> >
> >> I’d argue that it might cause the larger amount of problems as keeping
> >> references to data in the container is something that’s not used very
> >> often. But *everybody* will have tons of conversions between QList and
> >> QVector with your plan for unported code. IMO that’s just as bad.
> >
> > I disagree. See above. I'd like to add, if I may be so bold, that seeing
> just how widespread unintended detaches are _even in Qt code_, are you
> _actually_ going to tell me that copying a QVector into a QList is going to
> be _noticeable_? It has O(detach) complexity. Yes, in the 5% of code, it
> might get slower (if there wasn't an unintended detach to begin with), but
> as I said: it's easily identified with the simplest of tools: a profiler,
> and in normal testing. The correctness issue may be hiding in the 95% that
> is less well maintained.
>
> Profilers help with real hot spots. They don’t really help a lot if those
> things are spread all over your code base.
> >
> > Please tell me that I misunderstood you and that you are _not_ going to
> prefer to optimize for speed of _unported_ code, sacrificing correctness of
> the same?
>
> You conveniently didn’t quote the first part of my answer. I didn’t say
> that. I said I really want to ensure that we get a zero copy conversion
> between QList and QVector where this doesn’t imply (possible) incorrectness
> in the code. That’s the case for all types that are smaller than a pointer
> and movable.
>
> Lars
>
> >
> > Please?
> >
> > Thanks,
> > Marc
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/d

Re: [Development] QList for Qt 6

[Lars Knoll]

> On 24 May 2019, at 10:19, Mutz, Marc via Development 
>  wrote:
> 
> On 2019-05-24 09:35, Lars Knoll wrote:
>>> On 23 May 2019, at 13:26, Mutz, Marc via Development 
>>>  wrote:
> [...]
>>> You said that QList should vanish from Qt API. So we don't care. We'll have 
>>> that switch to make QList _be_ QVector for ese of porting, but as a 
>>> template alias. There's your zero-copy conversion :) That leaves users. And 
>>> I repeat: I'd leave QList alone (as QArrayList, possibly with always 
>>> IndirectLayout), and just have implicit deprecated conversions between 
>>> QArrayList and QVector. You shouldn't care about performance of unported 
>>> code: It's easy to target both Qt 5 and Qt 6 if you use auto for receiving 
>>> from Qt API. For sending to Qt API, it's a bit more tricky. You need to 
>>> ifdef or live with the implicit conversion in a Qt 6 build, but it's not 
>>> something that we should optimize for. Really. Don’t.
>> Sorry, but no. Larger performance regressions that are not really
>> visible/cought at compile time can be as large a headache to our users
>> as the non stable references to data in the container.
> 
> Sorry, you're comparing apples and oranges, iow: a performance issue with a 
> correctness issue. You cannot weigh them against each other. We need to 
> ensure that user code stays correct _first_, fast _second_. The first rule of 
> optimisation: Don't do it. The second rule: Don't do it _yet_. Write correct 
> code first, optimize later. You can't turn that around. It'd send a 
> catastrophic signal to Qt users.

Yes, both are different things. But for a user moving from Qt 5 to Qt 6, it 
mainly matters how he is affected by this. 

And there might be quite a few people who will never hit the problem with 
stability of references (because storing a reference to a member of the list is 
not that common), but they will be seeing performance issues because of the 
implicit (and hidden) conversion.

> 
> Here's how I see it: performance problems show up in testing, and are easily 
> identified by a profiler, a tool that is available on every platform and 
> everyone knows how to use it. Stability of references problems are found, if 
> at all, by memory sanitizers, something that much less people will be 
> familiar with, and, crucially, might hide in less-well tested code.
> 
>> I’d argue that it might cause the larger amount of problems as keeping
>> references to data in the container is something that’s not used very
>> often. But *everybody* will have tons of conversions between QList and
>> QVector with your plan for unported code. IMO that’s just as bad.
> 
> I disagree. See above. I'd like to add, if I may be so bold, that seeing just 
> how widespread unintended detaches are _even in Qt code_, are you _actually_ 
> going to tell me that copying a QVector into a QList is going to be 
> _noticeable_? It has O(detach) complexity. Yes, in the 5% of code, it might 
> get slower (if there wasn't an unintended detach to begin with), but as I 
> said: it's easily identified with the simplest of tools: a profiler, and in 
> normal testing. The correctness issue may be hiding in the 95% that is less 
> well maintained.

Profilers help with real hot spots. They don’t really help a lot if those 
things are spread all over your code base.
> 
> Please tell me that I misunderstood you and that you are _not_ going to 
> prefer to optimize for speed of _unported_ code, sacrificing correctness of 
> the same?

You conveniently didn’t quote the first part of my answer. I didn’t say that. I 
said I really want to ensure that we get a zero copy conversion between QList 
and QVector where this doesn’t imply (possible) incorrectness in the code. 
That’s the case for all types that are smaller than a pointer and movable.

Lars

> 
> Please?
> 
> Thanks,
> Marc
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Mutz, Marc via Development]

On 2019-05-24 09:35, Lars Knoll wrote:
On 23 May 2019, at 13:26, Mutz, Marc via Development 
 wrote:

[...]
You said that QList should vanish from Qt API. So we don't care. We'll 
have that switch to make QList _be_ QVector for ese of porting, but as 
a template alias. There's your zero-copy conversion :) That leaves 
users. And I repeat: I'd leave QList alone (as QArrayList, possibly 
with always IndirectLayout), and just have implicit deprecated 
conversions between QArrayList and QVector. You shouldn't care about 
performance of unported code: It's easy to target both Qt 5 and Qt 6 
if you use auto for receiving from Qt API. For sending to Qt API, it's 
a bit more tricky. You need to ifdef or live with the implicit 
conversion in a Qt 6 build, but it's not something that we should 
optimize for. Really. Don’t.


Sorry, but no. Larger performance regressions that are not really
visible/cought at compile time can be as large a headache to our users
as the non stable references to data in the container.


Sorry, you're comparing apples and oranges, iow: a performance issue 
with a correctness issue. You cannot weigh them against each other. We 
need to ensure that user code stays correct _first_, fast _second_. The 
first rule of optimisation: Don't do it. The second rule: Don't do it 
_yet_. Write correct code first, optimize later. You can't turn that 
around. It'd send a catastrophic signal to Qt users.


Here's how I see it: performance problems show up in testing, and are 
easily identified by a profiler, a tool that is available on every 
platform and everyone knows how to use it. Stability of references 
problems are found, if at all, by memory sanitizers, something that much 
less people will be familiar with, and, crucially, might hide in 
less-well tested code.



I’d argue that it might cause the larger amount of problems as keeping
references to data in the container is something that’s not used very
often. But *everybody* will have tons of conversions between QList and
QVector with your plan for unported code. IMO that’s just as bad.


I disagree. See above. I'd like to add, if I may be so bold, that seeing 
just how widespread unintended detaches are _even in Qt code_, are you 
_actually_ going to tell me that copying a QVector into a QList is going 
to be _noticeable_? It has O(detach) complexity. Yes, in the 5% of code, 
it might get slower (if there wasn't an unintended detach to begin 
with), but as I said: it's easily identified with the simplest of tools: 
a profiler, and in normal testing. The correctness issue may be hiding 
in the 95% that is less well maintained.


Please tell me that I misunderstood you and that you are _not_ going to 
prefer to optimize for speed of _unported_ code, sacrificing correctness 
of the same?


Please?

Thanks,
Marc

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lars Knoll]

> On 23 May 2019, at 13:26, Mutz, Marc via Development 
>  wrote:
> 
> On 2019-05-23 10:40, Lars Knoll wrote:
> [...]
 4. Use QVector to implement QList, if sizeof(Foo) <=
 sizeof(quint64) and Foo is movable. I’m intentionally not using
 sizeof(void *) here, as types with sizes between 4 and 8 bytes would
 not have stable references in cross platform code, so I do not believe
 lots of code would assume that (or it would have broken on 64 bit).
>>> Agreed. This matches what QList currently does, minus the padding, which is 
>>> good.
>> I tried this, and the problem here is that this requires T to be fully
>> declared at the time you instantiate QList. This is a source
>> incompatibility for class declarations such as
>> class MyClass {
>>  QList list;
>> };
>> This worked in Qt 5, but wouldn’t work here anymore as I can’t select
>> the implementation of QList for a forward declared class.
> 
> I agree we should not break this. The standard has just added similar 
> guarantees for it's own containers.
> 
>> At the same time, I’m not really willing to compromise on this point,
>> as I really want to have a zero copy conversion between QList and
>> QVector for small movable types (the most common case).
> 
> I don't see why a zero-copy conversion between QList and QVector for 
> vector-like QList is needed.

Because I don’t want to have larger performance regressions in our users code 
if we can avoid it.
> 
> You said that QList should vanish from Qt API. So we don't care. We'll have 
> that switch to make QList _be_ QVector for ese of porting, but as a template 
> alias. There's your zero-copy conversion :) That leaves users. And I repeat: 
> I'd leave QList alone (as QArrayList, possibly with always IndirectLayout), 
> and just have implicit deprecated conversions between QArrayList and QVector. 
> You shouldn't care about performance of unported code: It's easy to target 
> both Qt 5 and Qt 6 if you use auto for receiving from Qt API. For sending to 
> Qt API, it's a bit more tricky. You need to ifdef or live with the implicit 
> conversion in a Qt 6 build, but it's not something that we should optimize 
> for. Really. Don’t.

Sorry, but no. Larger performance regressions that are not really 
visible/cought at compile time can be as large a headache to our users as the 
non stable references to data in the container.

I’d argue that it might cause the larger amount of problems as keeping 
references to data in the container is something that’s not used very often. 
But *everybody* will have tons of conversions between QList and QVector with 
your plan for unported code. IMO that’s just as bad.

Cheers,
Lars

> 
> So, I'd try the following:
> 
> - have a compile switch that hides QList and replaces it with a template 
> alias to QVector. This is BC if you compiled with the switch off. Clients 
> using the alias will never see the QList name, so won't use the code compiled 
> into QtCore for it. So, no need to make it all-inline.
> 
>#if QList-as-QVector
>template  using QList = QVector;
>#else
>~~~ QList impl, unchanged, except for implicit deprecated conversions 
> to/from QVector added ~~~
>#endif
> 
> - port QtCore away from QList
> 
> - flip the switch (in CI) for all other libraries except QtCore (so QtCore 
> keeps compiling QList in, for other users)
> 
> - deal with the fallout
> 
> - once reasonably sure all stability-of-reference users have been ported away 
> from QList, do s/QList/QVector/g when convenient and unflip the switch in CI
> 
> - ok, so keep the switch for final release, buf off (and it never affects the 
> QtCore build)
> 
> - bonus: rename QList to QArrayList, using IndirectLayout unconditionally, 
> and make the name 'QList' a deprecated template alias for (depending on 
> compile switch) QArrayList (default) or QVector (for the fireworks). I'd go 
> to this length _only_ if we think that QArrayList (always IndirectLayout) is 
> a worthwhile container to have (remember, there's always vector) 
> and thus it's going to be maintained going forward. If it's not, I'd leave it 
> as QList and deprecate it.
> 
> Thanks,
> Marc
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Mutz, Marc via Development]

On 2019-05-23 10:40, Lars Knoll wrote:
[...]

4. Use QVector to implement QList, if sizeof(Foo) <=
sizeof(quint64) and Foo is movable. I’m intentionally not using
sizeof(void *) here, as types with sizes between 4 and 8 bytes would
not have stable references in cross platform code, so I do not 
believe

lots of code would assume that (or it would have broken on 64 bit).


Agreed. This matches what QList currently does, minus the padding, 
which is good.


I tried this, and the problem here is that this requires T to be fully
declared at the time you instantiate QList. This is a source
incompatibility for class declarations such as

class MyClass {
QList list;
};

This worked in Qt 5, but wouldn’t work here anymore as I can’t select
the implementation of QList for a forward declared class.


I agree we should not break this. The standard has just added similar 
guarantees for it's own containers.



At the same time, I’m not really willing to compromise on this point,
as I really want to have a zero copy conversion between QList and
QVector for small movable types (the most common case).


I don't see why a zero-copy conversion between QList and QVector for 
vector-like QList is needed.


You said that QList should vanish from Qt API. So we don't care. We'll 
have that switch to make QList _be_ QVector for ese of porting, but as a 
template alias. There's your zero-copy conversion :) That leaves users. 
And I repeat: I'd leave QList alone (as QArrayList, possibly with always 
IndirectLayout), and just have implicit deprecated conversions between 
QArrayList and QVector. You shouldn't care about performance of unported 
code: It's easy to target both Qt 5 and Qt 6 if you use auto for 
receiving from Qt API. For sending to Qt API, it's a bit more tricky. 
You need to ifdef or live with the implicit conversion in a Qt 6 build, 
but it's not something that we should optimize for. Really. Don't.


So, I'd try the following:

- have a compile switch that hides QList and replaces it with a template 
alias to QVector. This is BC if you compiled with the switch off. 
Clients using the alias will never see the QList name, so won't use the 
code compiled into QtCore for it. So, no need to make it all-inline.


#if QList-as-QVector
template  using QList = QVector;
#else
~~~ QList impl, unchanged, except for implicit deprecated 
conversions to/from QVector added ~~~

#endif

- port QtCore away from QList

- flip the switch (in CI) for all other libraries except QtCore (so 
QtCore keeps compiling QList in, for other users)


- deal with the fallout

- once reasonably sure all stability-of-reference users have been ported 
away from QList, do s/QList/QVector/g when convenient and unflip the 
switch in CI


- ok, so keep the switch for final release, buf off (and it never 
affects the QtCore build)


- bonus: rename QList to QArrayList, using IndirectLayout 
unconditionally, and make the name 'QList' a deprecated template alias 
for (depending on compile switch) QArrayList (default) or QVector (for 
the fireworks). I'd go to this length _only_ if we think that QArrayList 
(always IndirectLayout) is a worthwhile container to have (remember, 
there's always vector) and thus it's going to be maintained 
going forward. If it's not, I'd leave it as QList and deprecate it.


Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Konstantin Shegunov]

On Thu, May 23, 2019 at 12:15 PM Shawn Rutledge 
wrote:

> > On 23 May 2019, at 07:51, Konstantin Shegunov 
> wrote:
> > Yes, exactly like, though it'd need to regrow automatically; and on
> regrow it may need to normalize the order of elements (hence the
> "amortized”).
>
> When should it regrow?  It’s part of the definition that it overwrites the
> oldest elements when you try to insert too much data.
>

Yes, I meant specifically for the QQueue, we'd want it to grow so we can
accommodate the data. The most obvious thing that comes to mind for the
regrowth is when you need an element and the begin iterator (i.e. pointer)
is end iterator + 1. It does waste one element, but on the other hand
allows to easily distinguish between an empty buffer and a full one.


> I’m a big fan of the concept, have actually need one of these several
> times, and would like to see it moved to qtbase and made public


Makes sense to me.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lars Knoll]

> On 23 May 2019, at 11:50, Olivier Goffart  wrote:
> 
> On 22.05.19 15:49, Lars Knoll wrote:
> [...]
>> 2. Move QStringList and QByteArrayList over to inherit from QVector (that 
>> should be source compatible)
>> 3. Rename QStringList to QStringVector (keep QStringList as a compatibility 
>> name), same for QBAList
> 
> I wouldn't do that.
> I'd just make  using QStringList = QVector;
> and let QVector inherit from QVectorSpecialMethods which would be 
> specialized for QString and QByteArray (similar to what QListSpecialMethods 
> is today)

Of course, that’s what I actually meant :)

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Olivier Goffart]

On 22.05.19 15:49, Lars Knoll wrote:
[...]

2. Move QStringList and QByteArrayList over to inherit from QVector (that 
should be source compatible)
3. Rename QStringList to QStringVector (keep QStringList as a compatibility 
name), same for QBAList


I wouldn't do that.
I'd just make  using QStringList = QVector;
and let QVector inherit from QVectorSpecialMethods which would be 
specialized for QString and QByteArray (similar to what QListSpecialMethods is 
today)


--
Olivier
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Shawn Rutledge]

> On 23 May 2019, at 07:51, Konstantin Shegunov  wrote:
> 
> On Thu, May 23, 2019 at 8:12 AM Mutz, Marc via Development 
>  wrote:
> On 2019-05-22 22:38, Konstantin Shegunov wrote:
> > What about a rather smart (in terms of storage) circular buffer; a
> > vector. Then the push, pop, enqueue and dequeue would be amortized
> > O(1)?
> 
> You mean like QCircularBuffer?
> 
> Yes, exactly like, though it'd need to regrow automatically; and on regrow it 
> may need to normalize the order of elements (hence the "amortized”).

When should it regrow?  It’s part of the definition that it overwrites the 
oldest elements when you try to insert too much data.

I’m a big fan of the concept, have actually need one of these several times, 
and would like to see it moved to qtbase and made public, provided that the 
implementation is efficient and the API is maintainable (including for small 
numbers of small elements).  But we have several of them.  The so-called 
QRingBuffer is a different beast, and I am dubious that it’s the right solution 
even in its own use cases, let alone for general use.  IMO we should try to use 
a proper ring buffer/circular buffer template container to replace as many of 
these ring-buffer-like things as possible (there are really several of them).  
QPODVector velocityBuffer in the flickable implementation is a prime 
candidate to get replaced, for example (and in other cases where we are 
smoothing the velocity of something by keeping a running average).  Could we 
even agree that fixed-size (with size as a template parameter) is good enough?

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lars Knoll]

On 23 May 2019, at 10:40, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:

Hi,

Been trying to implement this, and of course there are some complications :)

On 22 May 2019, at 21:36, Mutz, Marc via Development 
mailto:development@qt-project.org>> wrote:

Hi Lars,

On 2019-05-22 15:49, Lars Knoll wrote:
Let’s conclude the topic of QList. I do see the concern about silent
source breakages. Here’s what we’ll (I’ll) do then for Qt 6:
1. Rename QList to QArrayList and make QList an alias to QArrayList

Agreed.

2. Move QStringList and QByteArrayList over to inherit from QVector
(that should be source compatible)

Agreed.

3. Rename QStringList to QStringVector (keep QStringList as a
compatibility name), same for QBAList

Not necessary, in my mind (List is a general concept, think ListView, not just 
a linked list). But not strongly opposed b/c/o the compat typedef.

4. Use QVector to implement QList, if sizeof(Foo) <=
sizeof(quint64) and Foo is movable. I’m intentionally not using
sizeof(void *) here, as types with sizes between 4 and 8 bytes would
not have stable references in cross platform code, so I do not believe
lots of code would assume that (or it would have broken on 64 bit).

Agreed. This matches what QList currently does, minus the padding, which is 
good.

I tried this, and the problem here is that this requires T to be fully declared 
at the time you instantiate QList. This is a source incompatibility for 
class declarations such as

class MyClass {
QList list;
};

This worked in Qt 5, but wouldn’t work here anymore as I can’t select the 
implementation of QList for a forward declared class.

At the same time, I’m not really willing to compromise on this point, as I 
really want to have a zero copy conversion between QList and QVector for small 
movable types (the most common case).

See https://codereview.qt-project.org/c/qt/qtbase/+/262602 for a WIP change 
implementing this.



5. Add a compile time switch that allows mapping QList completely to
QVector or to a compatibility mode where QLists of large/non movable
types are mapped to QArrayList

I agree with the compile-time switch, provided a) it defaults to QList as per 
(4), otherwise QArrayList (iow: Q5List behaviour minus the padding) and b) the 
switch goes away before Qt 6.0.0 is released. I see this as a way to help 
wip/qt6 get to all-vector APIs without breaking the world. So CI on wip/qt6 
would flip the switch to all-vector to see what breaks, at the same time the 
default would be to keep Q5List-mod-padding to not destroy git-bisect-ability 
across wip/qt6 commits.

6. For now we don’t yet want to explicitly change all our API that
uses QList to use QVector (as that would make merging from dev a pain,
let’s do that later this year). But to test that everything we have
works with QVector, we’ll set the compile switch to default to mapping
to QVector.

This is the only reason why I'd accept a compile switch, and that's why I'd 
very much like it to be gone by Qt 6, and why I think it shouldn't default to 
QVector. The CI can test with that (and with the old behaviour), individual 
developers may choose what they want, too, but the default for the wider 
audience tracking development should be backwards-compat. We don't want Qt to 
break for everyone because a few people are trying to eradicate the last 
reference-stability users.

I don’t see why you’d want to remove the switch for Qt 6. It would be a porting 
help for application developers.

7. Make the implementation of QArrayList fully inline and deprecate the class.

I don't think it needs to be fully inline, but I'm not opposed. If it's called 
QArrayList and always heap-allocates, incl. for , I'm also not sure it 
needs deprecating.

Let’s see. I agree that we should in this case consider it always using 
IndirectLayout to make it consistent and easy to understand.

Cheers,
Lars


Let me know if there are any major concerns with this plan. It should
give us a good compromise, where we can move all of Qt over to QVector
and test things early, as well as providing a compatibility mode for
our users (slower but won’t silently break).

To summarize: I agree with the plan, provided QList in Qt 6.0.0 unconditionally 
behaves like Q5List-mod-padding (upping the trigger from sizeof(void*) to 8 is 
ok, too), QList as as name is deprecated and as any type has implicit 
deprecated conversions from/to QVector.

Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lars Knoll]

Hi,

Been trying to implement this, and of course there are some complications :)

> On 22 May 2019, at 21:36, Mutz, Marc via Development 
>  wrote:
> 
> Hi Lars,
> 
> On 2019-05-22 15:49, Lars Knoll wrote:
>> Let’s conclude the topic of QList. I do see the concern about silent
>> source breakages. Here’s what we’ll (I’ll) do then for Qt 6:
>> 1. Rename QList to QArrayList and make QList an alias to QArrayList
> 
> Agreed.
> 
>> 2. Move QStringList and QByteArrayList over to inherit from QVector
>> (that should be source compatible)
> 
> Agreed.
> 
>> 3. Rename QStringList to QStringVector (keep QStringList as a
>> compatibility name), same for QBAList
> 
> Not necessary, in my mind (List is a general concept, think ListView, not 
> just a linked list). But not strongly opposed b/c/o the compat typedef.
> 
>> 4. Use QVector to implement QList, if sizeof(Foo) <=
>> sizeof(quint64) and Foo is movable. I’m intentionally not using
>> sizeof(void *) here, as types with sizes between 4 and 8 bytes would
>> not have stable references in cross platform code, so I do not believe
>> lots of code would assume that (or it would have broken on 64 bit).
> 
> Agreed. This matches what QList currently does, minus the padding, which is 
> good.

I tried this, and the problem here is that this requires T to be fully declared 
at the time you instantiate QList. This is a source incompatibility for 
class declarations such as

class MyClass {
QList list;
};

This worked in Qt 5, but wouldn’t work here anymore as I can’t select the 
implementation of QList for a forward declared class.

At the same time, I’m not really willing to compromise on this point, as I 
really want to have a zero copy conversion between QList and QVector for small 
movable types (the most common case).

> 
>> 5. Add a compile time switch that allows mapping QList completely to
>> QVector or to a compatibility mode where QLists of large/non movable
>> types are mapped to QArrayList
> 
> I agree with the compile-time switch, provided a) it defaults to QList as per 
> (4), otherwise QArrayList (iow: Q5List behaviour minus the padding) and b) 
> the switch goes away before Qt 6.0.0 is released. I see this as a way to help 
> wip/qt6 get to all-vector APIs without breaking the world. So CI on wip/qt6 
> would flip the switch to all-vector to see what breaks, at the same time the 
> default would be to keep Q5List-mod-padding to not destroy git-bisect-ability 
> across wip/qt6 commits.
> 
>> 6. For now we don’t yet want to explicitly change all our API that
>> uses QList to use QVector (as that would make merging from dev a pain,
>> let’s do that later this year). But to test that everything we have
>> works with QVector, we’ll set the compile switch to default to mapping
>> to QVector.
> 
> This is the only reason why I'd accept a compile switch, and that's why I'd 
> very much like it to be gone by Qt 6, and why I think it shouldn't default to 
> QVector. The CI can test with that (and with the old behaviour), individual 
> developers may choose what they want, too, but the default for the wider 
> audience tracking development should be backwards-compat. We don't want Qt to 
> break for everyone because a few people are trying to eradicate the last 
> reference-stability users.

I don’t see why you’d want to remove the switch for Qt 6. It would be a porting 
help for application developers.
> 
>> 7. Make the implementation of QArrayList fully inline and deprecate the 
>> class.
> 
> I don't think it needs to be fully inline, but I'm not opposed. If it's 
> called QArrayList and always heap-allocates, incl. for , I'm also not 
> sure it needs deprecating.

Let’s see. I agree that we should in this case consider it always using 
IndirectLayout to make it consistent and easy to understand.

Cheers,
Lars

> 
>> Let me know if there are any major concerns with this plan. It should
>> give us a good compromise, where we can move all of Qt over to QVector
>> and test things early, as well as providing a compatibility mode for
>> our users (slower but won’t silently break).
> 
> To summarize: I agree with the plan, provided QList in Qt 6.0.0 
> unconditionally behaves like Q5List-mod-padding (upping the trigger from 
> sizeof(void*) to 8 is ok, too), QList as as name is deprecated and as any 
> type has implicit deprecated conversions from/to QVector.
> 
> Thanks,
> Marc
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Konstantin Shegunov]

On Thu, May 23, 2019 at 8:12 AM Mutz, Marc via Development <
development@qt-project.org> wrote:

> On 2019-05-22 22:38, Konstantin Shegunov wrote:
> > What about a rather smart (in terms of storage) circular buffer; a
> > vector. Then the push, pop, enqueue and dequeue would be amortized
> > O(1)?
>
> You mean like QCircularBuffer?
>

Yes, exactly like, though it'd need to regrow automatically; and on regrow
it may need to normalize the order of elements (hence the "amortized").
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Mutz, Marc via Development]

On 2019-05-22 22:38, Konstantin Shegunov wrote:

What about a rather smart (in terms of storage) circular buffer; a
vector. Then the push, pop, enqueue and dequeue would be amortized
O(1)?


You mean like QCircularBuffer?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Thiago Macieira]

On Wednesday, 22 May 2019 13:38:31 PDT Konstantin Shegunov wrote:
> What about a rather smart (in terms of storage) circular buffer; a vector.
> Then the push, pop, enqueue and dequeue would be amortized O(1)?

That's why std::queue is an adaptor, not a container. You can choose the 
container it wraps.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Konstantin Shegunov]

On Wed, May 22, 2019 at 11:30 PM Thiago Macieira 
wrote:

> More important than the prepend (unshift) optimisation, QQueue benefits
> from
> the takeFirst (shift) optimisation. That can be added to QVector by making
> by
> moving the begin pointer.
>

What about a rather smart (in terms of storage) circular buffer; a vector.
Then the push, pop, enqueue and dequeue would be amortized O(1)?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Thiago Macieira]

On Wednesday, 22 May 2019 12:15:55 PDT Mutz, Marc via Development wrote:
> On 2019-05-22 18:25, Иван Комиссаров wrote:
> > What about fast prepend in [QList]
> 
> Please look at the source and do experiments. Years ago, I think I found
> that it's just not true. There's a prepend optimisation, yes, but it
> only kicks in if you _only_ do prepends. If you mix in but a single
> append, it falls apart. That's IIRC, AFAIR, etc.

More important than the prepend (unshift) optimisation, QQueue benefits from 
the takeFirst (shift) optimisation. That can be added to QVector by making by 
moving the begin pointer.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Mutz, Marc via Development]

Hi Lars,

On 2019-05-22 15:49, Lars Knoll wrote:

Let’s conclude the topic of QList. I do see the concern about silent
source breakages. Here’s what we’ll (I’ll) do then for Qt 6:

1. Rename QList to QArrayList and make QList an alias to QArrayList


Agreed.


2. Move QStringList and QByteArrayList over to inherit from QVector
(that should be source compatible)


Agreed.


3. Rename QStringList to QStringVector (keep QStringList as a
compatibility name), same for QBAList


Not necessary, in my mind (List is a general concept, think ListView, 
not just a linked list). But not strongly opposed b/c/o the compat 
typedef.



4. Use QVector to implement QList, if sizeof(Foo) <=
sizeof(quint64) and Foo is movable. I’m intentionally not using
sizeof(void *) here, as types with sizes between 4 and 8 bytes would
not have stable references in cross platform code, so I do not believe
lots of code would assume that (or it would have broken on 64 bit).


Agreed. This matches what QList currently does, minus the padding, which 
is good.



5. Add a compile time switch that allows mapping QList completely to
QVector or to a compatibility mode where QLists of large/non movable
types are mapped to QArrayList


I agree with the compile-time switch, provided a) it defaults to QList 
as per (4), otherwise QArrayList (iow: Q5List behaviour minus the 
padding) and b) the switch goes away before Qt 6.0.0 is released. I see 
this as a way to help wip/qt6 get to all-vector APIs without breaking 
the world. So CI on wip/qt6 would flip the switch to all-vector to see 
what breaks, at the same time the default would be to keep 
Q5List-mod-padding to not destroy git-bisect-ability across wip/qt6 
commits.



6. For now we don’t yet want to explicitly change all our API that
uses QList to use QVector (as that would make merging from dev a pain,
let’s do that later this year). But to test that everything we have
works with QVector, we’ll set the compile switch to default to mapping
to QVector.


This is the only reason why I'd accept a compile switch, and that's why 
I'd very much like it to be gone by Qt 6, and why I think it shouldn't 
default to QVector. The CI can test with that (and with the old 
behaviour), individual developers may choose what they want, too, but 
the default for the wider audience tracking development should be 
backwards-compat. We don't want Qt to break for everyone because a few 
people are trying to eradicate the last reference-stability users.


7. Make the implementation of QArrayList fully inline and deprecate the 
class.


I don't think it needs to be fully inline, but I'm not opposed. If it's 
called QArrayList and always heap-allocates, incl. for , I'm also 
not sure it needs deprecating.



Let me know if there are any major concerns with this plan. It should
give us a good compromise, where we can move all of Qt over to QVector
and test things early, as well as providing a compatibility mode for
our users (slower but won’t silently break).


To summarize: I agree with the plan, provided QList in Qt 6.0.0 
unconditionally behaves like Q5List-mod-padding (upping the trigger from 
sizeof(void*) to 8 is ok, too), QList as as name is deprecated and as 
any type has implicit deprecated conversions from/to QVector.


Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Allan Sandfeld Jensen]

On Mittwoch, 22. Mai 2019 20:18:55 CEST Giuseppe D'Angelo via Development 
wrote:
> Il 22/05/19 20:14, Konstantin Tokarev ha scritto:
> >>>   FWIW, std::deque is implemented as a peculiar data strucutre which is
> >>>  not really contiguous, and it may perform worse than QList in certain
> >>>  cases>> 
> >> [citation needed], as usual.
> > 
> > https://en.cppreference.com/w/cpp/container/deque
> > 
> > "As opposed to std::vector, the elements of a deque are not stored
> > contiguously: typical implementations use a sequence of individually
> > allocated fixed-size arrays, with additional bookkeeping, which means
> > indexed access to deque must perform two pointer dereferences, compared
> > to vector's indexed access which performs only one."
> Sure, but the question was about usage of a std::deque vs QList for fast
> prepending behavior, not for indexed access. 

Maybe check for any place using QQueue, which is derived from QList, and meant 
for that exact usage. Or are you arguing that no one uses that, or that noone 
should be using it?

Allan



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Mutz, Marc via Development]

On 2019-05-22 18:25, Иван Комиссаров wrote:

What about fast prepend in [QList]


Please look at the source and do experiments. Years ago, I think I found 
that it's just not true. There's a prepend optimisation, yes, but it 
only kicks in if you _only_ do prepends. If you mix in but a single 
append, it falls apart. That's IIRC, AFAIR, etc.


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Thiago Macieira]

On Wednesday, 22 May 2019 09:25:18 PDT Иван Комиссаров wrote:
> > 4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64)
> > and Foo is movable
> What about fast prepend in that case? People tend to use QList as a deque
> because of the fast prepend/take first

It's possible to implement that for QVector too, albeit in non-inline code.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[André Pönitz]

On Wed, May 22, 2019 at 09:02:13PM +0300, Konstantin Tokarev wrote:
> 
> 
> 22.05.2019, 20:55, "André Pönitz" :
> > On Wed, May 22, 2019 at 07:41:42PM +0300, Konstantin Tokarev wrote:
> >>  22.05.2019, 19:38, "Philippe" :
> >>  >>  People tend to use QList as a deque because of the fast prepend/take 
> >> first
> >>  >
> >>  > Simply, QArrayList should not be deprecated.
> >>  > It is also useful to store large objects that needs to be sorted.
> >>
> >>  In the latter QList can be replaced with std::vector>
> >>  or QVector>
> >
> > At the price of user code uglification.
> 
> template
> using UniquePtrVector = std::vector>;

Leaves you with '->' vs '.' on things that effectively value semantics.

And you can't overload '.' to 'fix' this.

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Konstantin Tokarev]

22.05.2019, 21:19, "Giuseppe D'Angelo" :
> Il 22/05/19 20:14, Konstantin Tokarev ha scritto:
    FWIW, std::deque is implemented as a peculiar data strucutre which is 
 not really contiguous, and it may perform worse than QList in certain cases
>>>  [citation needed], as usual.
>>  https://en.cppreference.com/w/cpp/container/deque
>>
>>  "As opposed to std::vector, the elements of a deque are not stored 
>> contiguously: typical implementations use a sequence of individually 
>> allocated fixed-size arrays, with additional bookkeeping, which means 
>> indexed access to deque must perform two pointer dereferences, compared to 
>> vector's indexed access which performs only one."
>
> Sure, but the question was about usage of a std::deque vs QList for fast
> prepending behavior, not for indexed access. Sticking to the same
> reference, it _also_ points out that appending at either extremity of
> std::deque is O(1) (vs. O(n) for QList). So, again, [citation needed].

Well, I didn't mean that _prepend_ operation may be slower for deque than for 
QList. It just can be that the same container needs both prepending and indexed 
access, and QList (or similar contiguous container with reserved prepend space) 
can be more benefiicial in total.

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Giuseppe D'Angelo via Development]

Il 22/05/19 20:14, Konstantin Tokarev ha scritto:

  FWIW, std::deque is implemented as a peculiar data strucutre which is not 
really contiguous, and it may perform worse than QList in certain cases

[citation needed], as usual.

https://en.cppreference.com/w/cpp/container/deque

"As opposed to std::vector, the elements of a deque are not stored contiguously: 
typical implementations use a sequence of individually allocated fixed-size arrays, with 
additional bookkeeping, which means indexed access to deque must perform two pointer 
dereferences, compared to vector's indexed access which performs only one."


Sure, but the question was about usage of a std::deque vs QList for fast 
prepending behavior, not for indexed access. Sticking to the same 
reference, it _also_ points out that appending at either extremity of 
std::deque is O(1) (vs. O(n) for QList). So, again, [citation needed].


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Konstantin Tokarev]

22.05.2019, 21:10, "Giuseppe D'Angelo via Development" 
:
> Il 22/05/19 18:32, Konstantin Tokarev ha scritto:
>>>  What about fast prepend in that case? People tend to use QList as a deque 
>>> because of the fast prepend/take first
>>  FWIW, std::deque is implemented as a peculiar data strucutre which is not 
>> really contiguous, and it may perform worse than QList in certain cases
>
> [citation needed], as usual.

https://en.cppreference.com/w/cpp/container/deque

"As opposed to std::vector, the elements of a deque are not stored 
contiguously: typical implementations use a sequence of individually allocated 
fixed-size arrays, with additional bookkeeping, which means indexed access to 
deque must perform two pointer dereferences, compared to vector's indexed 
access which performs only one."

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Giuseppe D'Angelo via Development]

Hi,

Il 22/05/19 15:49, Lars Knoll ha scritto:

1. Rename QList to QArrayList and make QList an alias to QArrayList
2. Move QStringList and QByteArrayList over to inherit from QVector (that 
should be source compatible)
3. Rename QStringList to QStringVector (keep QStringList as a compatibility 
name), same for QBAList
4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64) and 
Foo is movable. I’m intentionally not using sizeof(void *) here, as types with sizes 
between 4 and 8 bytes would not have stable references in cross platform code, so I do 
not believe lots of code would assume that (or it would have broken on 64 bit).


I'd argue to simply leave QList alone. There's little point at doing 
refactorings on it; if the idea is to keep it just as deprecated 
compatibility measure, why touching it at all? And why changing its 
behavior in any way if it's meant for _compatibility_?


(That's also why I'd prefer the name Qt5List or something like that.)


5. Add a compile time switch that allows mapping QList completely to QVector or 
to a compatibility mode where QLists of large/non movable types are mapped to 
QArrayList


So this switch has three positions:

1) QList = QArrayList (default)
2) QList = QVector for small+movable types, QArrayList otherwise
3) QList = QVector

?


6. For now we don’t yet want to explicitly change all our API that uses QList 
to use QVector (as that would make merging from dev a pain, let’s do that later 
this year). But to test that everything we have works with QVector, we’ll set 
the compile switch to default to mapping to QVector.


And add implicit conversions (on QArrayList) from/to QVector.



7. Make the implementation of QArrayList fully inline and deprecate the class.


Why fully inline?


Thank you,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Giuseppe D'Angelo via Development]

Il 22/05/19 18:32, Konstantin Tokarev ha scritto:

What about fast prepend in that case? People tend to use QList as a deque 
because of the fast prepend/take first

FWIW, std::deque is implemented as a peculiar data strucutre which is not 
really contiguous, and it may perform worse than QList in certain cases


[citation needed], as usual.

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

True. I am just trying to provide alternative view. I am perhaps
overexaggerating a bit, but I still think this is something that needs to
be considered.
And yeah, QList=QArrayList should definitely be a default setting

On Wed, May 22, 2019 at 9:00 PM Giuseppe D'Angelo 
wrote:

> Il 22/05/19 19:29, NIkolai Marchenko ha scritto:
> > I do not see how this addresses the issue. You are pushing the decision
> > to use the compile switch or not on the same userbase who couldn't be
> > bothered to port away from qlist in the first place.
> > You are essenitally asking: "Are you sure you aren't using qlist in
> > specific ways?"
> > And the likely answer in the end will be "Eh, ps ... hehehe"
> >
> > People will use the "faster" non compatible compilation switch and
> > *will* break their code. It won't be Qt's fault but it *will* be
> > perceived as such.
>
> This is highly debatable. Sure, there's lots of cargo cult mentality in
> the software industry, and this could be used to shift the blame on Qt.
> On the other hand there's only so much we can do in terms of warning
> users about the consequences of flipping the switch in their _pre
> existing_ code base.
>
> (Switch that I'd like to keep in the QList=QArrayList by default.)
>
> My 2 c,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Konstantin Tokarev]

22.05.2019, 20:55, "André Pönitz" :
> On Wed, May 22, 2019 at 07:41:42PM +0300, Konstantin Tokarev wrote:
>>  22.05.2019, 19:38, "Philippe" :
>>  >>  People tend to use QList as a deque because of the fast prepend/take 
>> first
>>  >
>>  > Simply, QArrayList should not be deprecated.
>>  > It is also useful to store large objects that needs to be sorted.
>>
>>  In the latter QList can be replaced with std::vector>
>>  or QVector>
>
> At the price of user code uglification.

template
using UniquePtrVector = std::vector>;

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Giuseppe D'Angelo via Development]

Il 22/05/19 19:29, NIkolai Marchenko ha scritto:
I do not see how this addresses the issue. You are pushing the decision 
to use the compile switch or not on the same userbase who couldn't be 
bothered to port away from qlist in the first place.
You are essenitally asking: "Are you sure you aren't using qlist in 
specific ways?"

And the likely answer in the end will be "Eh, ps ... hehehe"

People will use the "faster" non compatible compilation switch and 
*will* break their code. It won't be Qt's fault but it *will* be 
perceived as such.


This is highly debatable. Sure, there's lots of cargo cult mentality in 
the software industry, and this could be used to shift the blame on Qt. 
On the other hand there's only so much we can do in terms of warning 
users about the consequences of flipping the switch in their _pre 
existing_ code base.


(Switch that I'd like to keep in the QList=QArrayList by default.)

My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[André Pönitz]

On Wed, May 22, 2019 at 07:41:42PM +0300, Konstantin Tokarev wrote:
> 
> 
> 22.05.2019, 19:38, "Philippe" :
> >>  People tend to use QList as a deque because of the fast prepend/take first
> >
> > Simply, QArrayList should not be deprecated.
> > It is also useful to store large objects that needs to be sorted.
> 
> In the latter QList can be replaced with std::vector>
> or QVector>

At the price of user code uglification.

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

Ugh, apparently I answered to Lars directly instead of the whole ML >_< See
below

I do not see how this addresses the issue. You are pushing the decision to
use the compile switch or not on the same userbase who couldn't be bothered
to port away from qlist in the first place.
You are essenitally asking: "Are you sure you aren't using qlist in
specific ways?"
And the likely answer in the end will be "Eh, ps ... hehehe"

People will use the "faster" non compatible compilation switch and *will*
break their code. It won't be Qt's fault but it *will* be perceived as such.



On Wed, May 22, 2019 at 4:50 PM Lars Knoll  wrote:

> Let’s conclude the topic of QList. I do see the concern about silent
> source breakages. Here’s what we’ll (I’ll) do then for Qt 6:
>
> 1. Rename QList to QArrayList and make QList an alias to QArrayList
> 2. Move QStringList and QByteArrayList over to inherit from QVector (that
> should be source compatible)
> 3. Rename QStringList to QStringVector (keep QStringList as a
> compatibility name), same for QBAList
> 4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64)
> and Foo is movable. I’m intentionally not using sizeof(void *) here, as
> types with sizes between 4 and 8 bytes would not have stable references in
> cross platform code, so I do not believe lots of code would assume that (or
> it would have broken on 64 bit).
> 5. Add a compile time switch that allows mapping QList completely to
> QVector or to a compatibility mode where QLists of large/non movable types
> are mapped to QArrayList
> 6. For now we don’t yet want to explicitly change all our API that uses
> QList to use QVector (as that would make merging from dev a pain, let’s do
> that later this year). But to test that everything we have works with
> QVector, we’ll set the compile switch to default to mapping to QVector.
> 7. Make the implementation of QArrayList fully inline and deprecate the
> class.
>
> Let me know if there are any major concerns with this plan. It should give
> us a good compromise, where we can move all of Qt over to QVector and test
> things early, as well as providing a compatibility mode for our users
> (slower but won’t silently break).
>
> Cheers,
> Lars
>
> > On 21 May 2019, at 10:38, Giuseppe D'Angelo via Development <
> development@qt-project.org> wrote:
> >
> > Il 21/05/19 10:30, Konstantin Shegunov ha scritto:
> >> That's a hard one. Especially since very few could keep in their brain
> a list of the sizes of each and every one class from Qt. It also differs
> depending on architecture.
> >
> > I know. That's my point: we can't just break this level of source
> compatibility.
> >
> > Thanks,
> >
> > --
> > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> > KDAB (France) S.A.S., a KDAB Group company
> > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> > KDAB - The Qt, C++ and OpenGL Experts
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Konstantin Tokarev]

22.05.2019, 19:38, "Philippe" :
>>  People tend to use QList as a deque because of the fast prepend/take first
>
> Simply, QArrayList should not be deprecated.
> It is also useful to store large objects that needs to be sorted.

In the latter QList can be replaced with std::vector> or 
QVector>

>
> Philippe
>
> On Wed, 22 May 2019 18:25:18 +0200
>  ??  wrote:
>
>>  4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64) 
>> and Foo is movable
>>
>>  What about fast prepend in that case? People tend to use QList as a deque 
>> because of the fast prepend/take first
>>
>>   ??
>>
>>  22 ??? 2019 ?., ? 15:49, Lars Knoll  ???(?):
>>
>>  Let’s conclude the topic of QList. I do see the concern about silent source 
>> breakages. Here’s what we’ll (I’ll) do then for Qt 6:
>>
>>   1. Rename QList to QArrayList and make QList an alias to QArrayList
>>   2. Move QStringList and QByteArrayList over to inherit from QVector (that 
>> should be source compatible)
>>   3. Rename QStringList to QStringVector (keep QStringList as a 
>> compatibility name), same for QBAList
>>   4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64) 
>> and Foo is movable. I’m intentionally not using sizeof(void *) here, as 
>> types with sizes between 4 and 8 bytes would not have stable references in 
>> cross platform code, so I do not believe lots of code would assume that (or 
>> it would have broken on 64 bit).
>>   5. Add a compile time switch that allows mapping QList completely to 
>> QVector or to a compatibility mode where QLists of large/non movable types 
>> are mapped to QArrayList
>>   6. For now we don’t yet want to explicitly change all our API that uses 
>> QList to use QVector (as that would make merging from dev a pain, let’s do 
>> that later this year). But to test that everything we have works with 
>> QVector, we’ll set the compile switch to default to mapping to QVector.
>>   7. Make the implementation of QArrayList fully inline and deprecate the 
>> class.
>>
>>   Let me know if there are any major concerns with this plan. It should give 
>> us a good compromise, where we can move all of Qt over to QVector and test 
>> things early, as well as providing a compatibility mode for our users 
>> (slower but won’t silently break).
>>
>>   Cheers,
>>   Lars
>>
>>   On 21 May 2019, at 10:38, Giuseppe D'Angelo via Development 
>>  wrote:
>>
>>  Il 21/05/19 10:30, Konstantin Shegunov ha scritto:
>>  That's a hard one. Especially since very few could keep in their brain a 
>> list of the sizes of each and every one class from Qt. It also differs 
>> depending on architecture.
>>
>>  I know. That's my point: we can't just break this level of source 
>> compatibility.
>>
>>  Thanks,
>>
>>  --
>>  Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
>>  KDAB (France) S.A.S., a KDAB Group company
>>  Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
>>  KDAB - The Qt, C++ and OpenGL Experts
>>
>>  ___
>>  Development mailing list
>>  Development@qt-project.org
>>  https://lists.qt-project.org/listinfo/development
>>
>>  ___
>>  Development mailing list
>>  Development@qt-project.org
>>  https://lists.qt-project.org/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Philippe]

> People tend to use QList as a deque because of the fast prepend/take first

Simply, QArrayList should not be deprecated.
It is also useful to store large objects that needs to be sorted.

Philippe

On Wed, 22 May 2019 18:25:18 +0200
 ??  wrote:

> 4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64) and 
> Foo is movable
> 
> 
> What about fast prepend in that case? People tend to use QList as a deque 
> because of the fast prepend/take first
> 
>  ??
> 
> 22 ??? 2019 ?., ? 15:49, Lars Knoll  ???(?):
> 
> 
> Let’s conclude the topic of QList. I do see the concern about silent source 
> breakages. Here’s what we’ll (I’ll) do then for Qt 6:
>  
>  1. Rename QList to QArrayList and make QList an alias to QArrayList
>  2. Move QStringList and QByteArrayList over to inherit from QVector (that 
> should be source compatible)
>  3. Rename QStringList to QStringVector (keep QStringList as a compatibility 
> name), same for QBAList
>  4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64) 
> and Foo is movable. I’m intentionally not using sizeof(void *) here, as types 
> with sizes between 4 and 8 bytes would not have stable references in cross 
> platform code, so I do not believe lots of code would assume that (or it 
> would have broken on 64 bit).
>  5. Add a compile time switch that allows mapping QList completely to QVector 
> or to a compatibility mode where QLists of large/non movable types are mapped 
> to QArrayList
>  6. For now we don’t yet want to explicitly change all our API that uses 
> QList to use QVector (as that would make merging from dev a pain, let’s do 
> that later this year). But to test that everything we have works with 
> QVector, we’ll set the compile switch to default to mapping to QVector.
>  7. Make the implementation of QArrayList fully inline and deprecate the 
> class.
>  
>  Let me know if there are any major concerns with this plan. It should give 
> us a good compromise, where we can move all of Qt over to QVector and test 
> things early, as well as providing a compatibility mode for our users (slower 
> but won’t silently break).
>  
>  Cheers,
>  Lars
>  
>  On 21 May 2019, at 10:38, Giuseppe D'Angelo via Development 
>  wrote:
> 
> Il 21/05/19 10:30, Konstantin Shegunov ha scritto:
> That's a hard one. Especially since very few could keep in their brain a list 
> of the sizes of each and every one class from Qt. It also differs depending 
> on architecture.
> 
> I know. That's my point: we can't just break this level of source 
> compatibility.
> 
> Thanks,
> 
> -- 
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Konstantin Tokarev]

22.05.2019, 19:28, "Иван Комиссаров" :
>> 4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64) 
>> and Foo is movable
>
> What about fast prepend in that case? People tend to use QList as a deque 
> because of the fast prepend/take first

FWIW, std::deque is implemented as a peculiar data strucutre which is not 
really contiguous, and it may perform worse than QList in certain cases


-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Иван Комиссаров]

> 4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64) and 
> Foo is movable

What about fast prepend in that case? People tend to use QList as a deque 
because of the fast prepend/take first

Иван Комиссаров

> 22 мая 2019 г., в 15:49, Lars Knoll  написал(а):
> 
> Let’s conclude the topic of QList. I do see the concern about silent source 
> breakages. Here’s what we’ll (I’ll) do then for Qt 6:
> 
> 1. Rename QList to QArrayList and make QList an alias to QArrayList
> 2. Move QStringList and QByteArrayList over to inherit from QVector (that 
> should be source compatible)
> 3. Rename QStringList to QStringVector (keep QStringList as a compatibility 
> name), same for QBAList
> 4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64) and 
> Foo is movable. I’m intentionally not using sizeof(void *) here, as types 
> with sizes between 4 and 8 bytes would not have stable references in cross 
> platform code, so I do not believe lots of code would assume that (or it 
> would have broken on 64 bit).
> 5. Add a compile time switch that allows mapping QList completely to QVector 
> or to a compatibility mode where QLists of large/non movable types are mapped 
> to QArrayList
> 6. For now we don’t yet want to explicitly change all our API that uses QList 
> to use QVector (as that would make merging from dev a pain, let’s do that 
> later this year). But to test that everything we have works with QVector, 
> we’ll set the compile switch to default to mapping to QVector.
> 7. Make the implementation of QArrayList fully inline and deprecate the class.
> 
> Let me know if there are any major concerns with this plan. It should give us 
> a good compromise, where we can move all of Qt over to QVector and test 
> things early, as well as providing a compatibility mode for our users (slower 
> but won’t silently break).
> 
> Cheers,
> Lars
> 
>> On 21 May 2019, at 10:38, Giuseppe D'Angelo via Development 
>>  wrote:
>> 
>> Il 21/05/19 10:30, Konstantin Shegunov ha scritto:
>>> That's a hard one. Especially since very few could keep in their brain a 
>>> list of the sizes of each and every one class from Qt. It also differs 
>>> depending on architecture.
>> 
>> I know. That's my point: we can't just break this level of source 
>> compatibility.
>> 
>> Thanks,
>> 
>> -- 
>> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
>> KDAB (France) S.A.S., a KDAB Group company
>> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
>> KDAB - The Qt, C++ and OpenGL Experts
>> 
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lars Knoll]

Let’s conclude the topic of QList. I do see the concern about silent source 
breakages. Here’s what we’ll (I’ll) do then for Qt 6:

1. Rename QList to QArrayList and make QList an alias to QArrayList
2. Move QStringList and QByteArrayList over to inherit from QVector (that 
should be source compatible)
3. Rename QStringList to QStringVector (keep QStringList as a compatibility 
name), same for QBAList
4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64) and 
Foo is movable. I’m intentionally not using sizeof(void *) here, as types with 
sizes between 4 and 8 bytes would not have stable references in cross platform 
code, so I do not believe lots of code would assume that (or it would have 
broken on 64 bit).
5. Add a compile time switch that allows mapping QList completely to QVector or 
to a compatibility mode where QLists of large/non movable types are mapped to 
QArrayList
6. For now we don’t yet want to explicitly change all our API that uses QList 
to use QVector (as that would make merging from dev a pain, let’s do that later 
this year). But to test that everything we have works with QVector, we’ll set 
the compile switch to default to mapping to QVector.
7. Make the implementation of QArrayList fully inline and deprecate the class.

Let me know if there are any major concerns with this plan. It should give us a 
good compromise, where we can move all of Qt over to QVector and test things 
early, as well as providing a compatibility mode for our users (slower but 
won’t silently break).

Cheers,
Lars

> On 21 May 2019, at 10:38, Giuseppe D'Angelo via Development 
>  wrote:
> 
> Il 21/05/19 10:30, Konstantin Shegunov ha scritto:
>> That's a hard one. Especially since very few could keep in their brain a 
>> list of the sizes of each and every one class from Qt. It also differs 
>> depending on architecture.
> 
> I know. That's my point: we can't just break this level of source 
> compatibility.
> 
> Thanks,
> 
> -- 
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Giuseppe D'Angelo via Development]

Il 21/05/19 10:30, Konstantin Shegunov ha scritto:
That's a hard one. Especially since very few could keep in their brain a 
list of the sizes of each and every one class from Qt. It also differs 
depending on architecture.


I know. That's my point: we can't just break this level of source 
compatibility.


Thanks,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Konstantin Shegunov]

On Tue, May 21, 2019 at 11:04 AM Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:

> which ones of the following guarantee
> integrity of references, i.e., _heap allocate every single element?
>

That's a hard one. Especially since very few could keep in their brain a
list of the sizes of each and every one class from Qt. It also differs
depending on architecture.
For example:
QList may (does on x86, doesn't on x64),
while
QList for sure does.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Giuseppe D'Angelo via Development]

Il 20/05/19 19:08, NIkolai Marchenko ha scritto:
This rather nicely proves my point. Jason isn't even new to this list 
and he didn't realize the problems.
No, community as a whole did _not _ have "years and years" to port away 
from QList


Here's the practical QList test: which ones of the following guarantee 
integrity of references, i.e., _heap allocate every single element? (The 
problem is that someone may rely on this property. __Qt itself_ has 
codepaths relying on it.)


1) QList
2) QList
3) QList
4) QList
5) QList
6) QList
7) QList // where: struct MyPoint { int x, y; };
8) QList>
9) QList>
10) QList
11) QList
12) QList
13) QList
14) QList
15) QList
16) QList>
17) QList>

Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Jason H]

Hey wait, I knew that at one point in time. I've been using Qt since 3.3. I 
can't keep track of all the magic under the hood. 

I just hope i was right about the rest. And some judge things based off me. I 
am violently thrown around between Qt, Python, Java, JavaScript projects. It's 
a miracle that my code works at all.

> Sent: Monday, May 20, 2019 at 7:08 PM
> From: "NIkolai Marchenko" 
> To: "Jean-Michaël Celerier" 
> Cc: "Jason H" , "Qt development mailing list" 
> , "Mutz, Marc" 
> Subject: Re: [Development] QList for Qt 6
>
> This rather nicely proves my point. Jason isn't even new to this list and
> he didn't realize the problems.
> No, community as a whole did _not _ have "years and years" to port away
> from QList
> 
> On Mon, May 20, 2019 at 6:07 PM Jean-Michaël Celerier <
> jeanmichael.celer...@gmail.com> wrote:
> 
> > > QList is just a linked list
> >
> > you're in for a rude awakening :-) https://doc.qt.io/qt-5/qlist.html
> >
> > On Mon, May 20, 2019 at 5:03 PM Jason H  wrote:
> >
> >>
> >> > Ok, QList as an alias for QVector takes care of the technical issues I
> >> > have with using inheritance. It doesn't address my concerns regarding
> >> > breaking QList behaviour. What purpose is served to call something QList
> >> > that is in fact a QVector? Please spell it out for me, as I don't see
> >> > it.
> >>
> >> My understanding is that QVector requires contiguous memory, consuming a
> >> giant block for all the items in the list. QList is just a linked list.
> >> QVector will fail sooner when memory fragmentation is a problem. I would
> >> expect systems with long-running processes and limited RAM (i.e. embedded,
> >> a Raspberry Pi, phone, etc) to encounter this sooner than other systems,
> >> especially when the size of each object is large. (You could always just
> >> store pointers though)
> >>
> >>
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> https://lists.qt-project.org/listinfo/development
> >>
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> >
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6 (was: Re: Build system for Qt 6)

[Allan Sandfeld Jensen]

On Freitag, 2. November 2018 08:51:22 CEST Lars Knoll wrote:
> Renaming the subthread (it’s got nothing to do with build systems…)
> 
> I believe I have a solution to get rid of QList without breaking SC in any
> major way. See https://codereview.qt-project.org/#/c/242199/ and the
> following changes.
 
> I did some benchmarking (as we were worried about the different performance
> characteristics of QList and QVector) and with the exception of prepending
> in a loop pretty much all other operations gets faster with this change.
 
> So to re-iterate: We will not break SC in major ways. The goal is to make
> porting from Qt 5.x to 6 as easy as possible.
 
Would we have a different implementation for QQueue then? One of the few 
benefits of QList was the prepend optimization, which is mostly unused, except 
in QQueue. Perhaps the current QList definition could just become QQueue?

'Allan


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

This rather nicely proves my point. Jason isn't even new to this list and
he didn't realize the problems.
No, community as a whole did _not _ have "years and years" to port away
from QList

On Mon, May 20, 2019 at 6:07 PM Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:

> > QList is just a linked list
>
> you're in for a rude awakening :-) https://doc.qt.io/qt-5/qlist.html
>
> On Mon, May 20, 2019 at 5:03 PM Jason H  wrote:
>
>>
>> > Ok, QList as an alias for QVector takes care of the technical issues I
>> > have with using inheritance. It doesn't address my concerns regarding
>> > breaking QList behaviour. What purpose is served to call something QList
>> > that is in fact a QVector? Please spell it out for me, as I don't see
>> > it.
>>
>> My understanding is that QVector requires contiguous memory, consuming a
>> giant block for all the items in the list. QList is just a linked list.
>> QVector will fail sooner when memory fragmentation is a problem. I would
>> expect systems with long-running processes and limited RAM (i.e. embedded,
>> a Raspberry Pi, phone, etc) to encounter this sooner than other systems,
>> especially when the size of each object is large. (You could always just
>> store pointers though)
>>
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Jean-Michaël Celerier]

> QList is just a linked list

you're in for a rude awakening :-) https://doc.qt.io/qt-5/qlist.html

On Mon, May 20, 2019 at 5:03 PM Jason H  wrote:

>
> > Ok, QList as an alias for QVector takes care of the technical issues I
> > have with using inheritance. It doesn't address my concerns regarding
> > breaking QList behaviour. What purpose is served to call something QList
> > that is in fact a QVector? Please spell it out for me, as I don't see
> > it.
>
> My understanding is that QVector requires contiguous memory, consuming a
> giant block for all the items in the list. QList is just a linked list.
> QVector will fail sooner when memory fragmentation is a problem. I would
> expect systems with long-running processes and limited RAM (i.e. embedded,
> a Raspberry Pi, phone, etc) to encounter this sooner than other systems,
> especially when the size of each object is large. (You could always just
> store pointers though)
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Jason H]

> Ok, QList as an alias for QVector takes care of the technical issues I
> have with using inheritance. It doesn't address my concerns regarding
> breaking QList behaviour. What purpose is served to call something QList
> that is in fact a QVector? Please spell it out for me, as I don't see
> it.

My understanding is that QVector requires contiguous memory, consuming a giant 
block for all the items in the list. QList is just a linked list. QVector will 
fail sooner when memory fragmentation is a problem. I would expect systems with 
long-running processes and limited RAM (i.e. embedded, a Raspberry Pi, phone, 
etc) to encounter this sooner than other systems, especially when the size of 
each object is large. (You could always just store pointers though)


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Mutz, Marc via Development]

On 2019-05-20 15:52, Lars Knoll wrote:

Hi Marc,


On 20 May 2019, at 14:39, Mutz, Marc via Development
 wrote:

Hi Lars,

I'm on record for claiming QList needs to die, and I work for a
company that still makes part of its living by porting Qt 3 apps to
Qt 4 (and 5). So I should be celebrating if you create more
potential work for KDAB, but I'm actually ok with keeping QList.

Provided it vanishes from each and every Qt API.

Whether to call it Q5List or QArrayList or continue with QList
doesn't matter. Actually, I'd err on keeping QList, to minimize
porting. What I want to avoid is to break user code silently. Asan
is a runtime-checker, the code must actually be exercised, which is
trivial for QToolBox but might be problematic if it's in, say, error
handling code. And you rightfully pointed out that it's very hard
for a static checker to find cases where reference stability is
used. Not impossible, but hard.

I want to understand what problems you see with keeping QList as-is
with deprecated implicit conversions to and from QVector, assuming
all Qt API that uses QList is ported to QVector.

The way I see it:

Given:
* QList stays as-is
* No Qt API takes or returns QList anymore, but QVector
* QList implicitly converts to QVector, and vice versa
* These implicit conversions are marked as deprecated

Pros:
* Old (user) code doesn't silently change the meaning
* Old (user) code continues to work, lets users port at their own
leisure
* Receiving objects can be done with auto variables for optimal
performance
or with QList for old code.
* Users passing QLists into Qt APIs enjoy the implicit conversion to
QVector
+ This might be slow, but you say yourself that speed doesn't
matter
for 95% of the code and it's easier to find and fix slow code in
the 5% than it is to find a silent reference stability breakage
in
the 95%.

Cons:
* Unported code will get penalized by the implicit conversions from
and to QList
+ But using the 95/5-argument here, again: it's easier to find
where the app
got slower in the 5% than to find a bug in the 95%.

The pros far, far outweigh the cons. I'd very much like to know in
which aspects inheriting QList from QVector fares better than this
proposal.


 I’m not proposing to make QList inherit QVector. Actually, I’m
making it an alias to QVector. See
https://codereview.qt-project.org/c/qt/qtbase/+/242692 .

With that, one option could be to make the alias dependent on a
compile time setting for the application code (ie. have a simple
define whether we do

using QList = QVector

Or

using QList = Qt5Support::QList


Ok, QList as an alias for QVector takes care of the technical issues I 
have with using inheritance. It doesn't address my concerns regarding 
breaking QList behaviour. What purpose is served to call something QList 
that is in fact a QVector? Please spell it out for me, as I don't see 
it.



My fear is that QList : QVector will lead to some of Qt's APIs
continuing to use QList, which would lock Qt into QList for another
major release cycle and only postpone the inevitable QList removal.


No, of course we need to get rid of all references to QList in our
APIs.


I appreciate that commitment very much.

Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Jason H]

My only conern about QList/QVector is a minor one: that the api be more accomodating to cross-language people. push()/append(), size() and length/length(). 

Now that Qt is thoroughly supporting Python, and JS, and C++ , and implicit conversions, having an API that is normal for any of the languages is, I think, important. This also applies to QML models, which use size() and not length. It;s rather leaky abstraction to allow JS arrays as models, which use length, and "proper" QML models which use size. This is friction that I don't think needs to exist?

 

 

 

Sent: Monday, May 20, 2019 at 9:52 AM
From: "Lars Knoll" 
To: "Mutz, Marc" 
Cc: "Qt development mailing list" 
Subject: Re: [Development] QList for Qt 6


Hi Marc,
 

On 20 May 2019, at 14:39, Mutz, Marc via Development <development@qt-project.org> wrote:
 


Hi Lars,

I'm on record for claiming QList needs to die, and I work for a company that still makes part of its living by porting Qt 3 apps to Qt 4 (and 5). So I should be celebrating if you create more potential work for KDAB, but I'm actually ok with keeping QList.

Provided it vanishes from each and every Qt API.

Whether to call it Q5List or QArrayList or continue with QList doesn't matter. Actually, I'd err on keeping QList, to minimize porting. What I want to avoid is to break user code silently. Asan is a runtime-checker, the code must actually be exercised, which is trivial for QToolBox but might be problematic if it's in, say, error handling code. And you rightfully pointed out that it's very hard for a static checker to find cases where reference stability is used. Not impossible, but hard.

I want to understand what problems you see with keeping QList as-is with deprecated implicit conversions to and from QVector, assuming all Qt API that uses QList is ported to QVector.

The way I see it:

Given:
* QList stays as-is
* No Qt API takes or returns QList anymore, but QVector
* QList implicitly converts to QVector, and vice versa
* These implicit conversions are marked as deprecated

Pros:
* Old (user) code doesn't silently change the meaning
* Old (user) code continues to work, lets users port at their own leisure
* Receiving objects can be done with auto variables for optimal performance
 or with QList for old code.
* Users passing QLists into Qt APIs enjoy the implicit conversion to QVector
 + This might be slow, but you say yourself that speed doesn't matter
   for 95% of the code and it's easier to find and fix slow code in
   the 5% than it is to find a silent reference stability breakage in
   the 95%.

Cons:
* Unported code will get penalized by the implicit conversions from and to QList
 + But using the 95/5-argument here, again: it's easier to find where the app
   got slower in the 5% than to find a bug in the 95%.

The pros far, far outweigh the cons. I'd very much like to know in which aspects inheriting QList from QVector fares better than this proposal.



 
I’m not proposing to make QList inherit QVector. Actually, I’m making it an alias to QVector. See https://codereview.qt-project.org/c/qt/qtbase/+/242692 . 

 

With that, one option could be to make the alias dependent on a compile time setting for the application code (ie. have a simple define whether we do

 

using QList = QVector

 

Or 

 


using QList = Qt5Support::QList

 






My fear is that QList : QVector will lead to some of Qt's APIs continuing to use QList, which would lock Qt into QList for another major release cycle and only postpone the inevitable QList removal.



 

No, of course we need to get rid of all references to QList in our APIs.
 



C++11 gave us the tools to make this transition now much smoother than it could have been done in Qt 4->5. Inheriting QList from QVector is both technically wrong (value classes inheriting each other) and just serves to confuse users (is it still ok to use QList? Is it now suddenly ok after it wasn't in Qt 5? What do to if I target both Qt 5 and Qt 6?).



 
See above. The change where they inherit from each other is an intermediate change, not the final result.

 

Cheers,

Lars

 





Touché on the QStringView reference :)

Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development




___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lars Knoll]

Hi Marc,

On 20 May 2019, at 14:39, Mutz, Marc via Development 
mailto:development@qt-project.org>> wrote:

Hi Lars,

I'm on record for claiming QList needs to die, and I work for a company that 
still makes part of its living by porting Qt 3 apps to Qt 4 (and 5). So I 
should be celebrating if you create more potential work for KDAB, but I'm 
actually ok with keeping QList.

Provided it vanishes from each and every Qt API.

Whether to call it Q5List or QArrayList or continue with QList doesn't matter. 
Actually, I'd err on keeping QList, to minimize porting. What I want to avoid 
is to break user code silently. Asan is a runtime-checker, the code must 
actually be exercised, which is trivial for QToolBox but might be problematic 
if it's in, say, error handling code. And you rightfully pointed out that it's 
very hard for a static checker to find cases where reference stability is used. 
Not impossible, but hard.

I want to understand what problems you see with keeping QList as-is with 
deprecated implicit conversions to and from QVector, assuming all Qt API that 
uses QList is ported to QVector.

The way I see it:

Given:
* QList stays as-is
* No Qt API takes or returns QList anymore, but QVector
* QList implicitly converts to QVector, and vice versa
* These implicit conversions are marked as deprecated

Pros:
* Old (user) code doesn't silently change the meaning
* Old (user) code continues to work, lets users port at their own leisure
* Receiving objects can be done with auto variables for optimal performance
 or with QList for old code.
* Users passing QLists into Qt APIs enjoy the implicit conversion to QVector
 + This might be slow, but you say yourself that speed doesn't matter
   for 95% of the code and it's easier to find and fix slow code in
   the 5% than it is to find a silent reference stability breakage in
   the 95%.

Cons:
* Unported code will get penalized by the implicit conversions from and to QList
 + But using the 95/5-argument here, again: it's easier to find where the app
   got slower in the 5% than to find a bug in the 95%.

The pros far, far outweigh the cons. I'd very much like to know in which 
aspects inheriting QList from QVector fares better than this proposal.

I’m not proposing to make QList inherit QVector. Actually, I’m making it an 
alias to QVector. See https://codereview.qt-project.org/c/qt/qtbase/+/242692 .

With that, one option could be to make the alias dependent on a compile time 
setting for the application code (ie. have a simple define whether we do

using QList = QVector

Or

using QList = Qt5Support::QList


My fear is that QList : QVector will lead to some of Qt's APIs continuing to 
use QList, which would lock Qt into QList for another major release cycle and 
only postpone the inevitable QList removal.

No, of course we need to get rid of all references to QList in our APIs.

C++11 gave us the tools to make this transition now much smoother than it could 
have been done in Qt 4->5. Inheriting QList from QVector is both technically 
wrong (value classes inheriting each other) and just serves to confuse users 
(is it still ok to use QList? Is it now suddenly ok after it wasn't in Qt 5? 
What do to if I target both Qt 5 and Qt 6?).

See above. The change where they inherit from each other is an intermediate 
change, not the final result.

Cheers,
Lars


Touché on the QStringView reference :)

Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

For the record: I would also prefer QList to vanish from Qt's interfaces
rather than change its meaning everywhere it's used.
Better have explicit porting than subtle hard to track bugs.

On Mon, May 20, 2019 at 3:41 PM Mutz, Marc via Development <
development@qt-project.org> wrote:

> Hi Lars,
>
> I'm on record for claiming QList needs to die, and I work for a company
> that still makes part of its living by porting Qt 3 apps to Qt 4 (and
> 5). So I should be celebrating if you create more potential work for
> KDAB, but I'm actually ok with keeping QList.
>
> Provided it vanishes from each and every Qt API.
>
> Whether to call it Q5List or QArrayList or continue with QList doesn't
> matter. Actually, I'd err on keeping QList, to minimize porting. What I
> want to avoid is to break user code silently. Asan is a runtime-checker,
> the code must actually be exercised, which is trivial for QToolBox but
> might be problematic if it's in, say, error handling code. And you
> rightfully pointed out that it's very hard for a static checker to find
> cases where reference stability is used. Not impossible, but hard.
>
> I want to understand what problems you see with keeping QList as-is with
> deprecated implicit conversions to and from QVector, assuming all Qt API
> that uses QList is ported to QVector.
>
> The way I see it:
>
> Given:
> * QList stays as-is
> * No Qt API takes or returns QList anymore, but QVector
> * QList implicitly converts to QVector, and vice versa
> * These implicit conversions are marked as deprecated
>
> Pros:
> * Old (user) code doesn't silently change the meaning
> * Old (user) code continues to work, lets users port at their own
> leisure
> * Receiving objects can be done with auto variables for optimal
> performance
>or with QList for old code.
> * Users passing QLists into Qt APIs enjoy the implicit conversion to
> QVector
>+ This might be slow, but you say yourself that speed doesn't matter
>  for 95% of the code and it's easier to find and fix slow code in
>  the 5% than it is to find a silent reference stability breakage in
>  the 95%.
>
> Cons:
> * Unported code will get penalized by the implicit conversions from and
> to QList
>+ But using the 95/5-argument here, again: it's easier to find where
> the app
>  got slower in the 5% than to find a bug in the 95%.
>
> The pros far, far outweigh the cons. I'd very much like to know in which
> aspects inheriting QList from QVector fares better than this proposal.
>
> My fear is that QList : QVector will lead to some of Qt's APIs
> continuing to use QList, which would lock Qt into QList for another
> major release cycle and only postpone the inevitable QList removal.
> C++11 gave us the tools to make this transition now much smoother than
> it could have been done in Qt 4->5. Inheriting QList from QVector is
> both technically wrong (value classes inheriting each other) and just
> serves to confuse users (is it still ok to use QList? Is it now suddenly
> ok after it wasn't in Qt 5? What do to if I target both Qt 5 and Qt 6?).
>
> Touché on the QStringView reference :)
>
> Thanks,
> Marc
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Mutz, Marc via Development]

Hi Lars,

I'm on record for claiming QList needs to die, and I work for a company 
that still makes part of its living by porting Qt 3 apps to Qt 4 (and 
5). So I should be celebrating if you create more potential work for 
KDAB, but I'm actually ok with keeping QList.


Provided it vanishes from each and every Qt API.

Whether to call it Q5List or QArrayList or continue with QList doesn't 
matter. Actually, I'd err on keeping QList, to minimize porting. What I 
want to avoid is to break user code silently. Asan is a runtime-checker, 
the code must actually be exercised, which is trivial for QToolBox but 
might be problematic if it's in, say, error handling code. And you 
rightfully pointed out that it's very hard for a static checker to find 
cases where reference stability is used. Not impossible, but hard.


I want to understand what problems you see with keeping QList as-is with 
deprecated implicit conversions to and from QVector, assuming all Qt API 
that uses QList is ported to QVector.


The way I see it:

Given:
* QList stays as-is
* No Qt API takes or returns QList anymore, but QVector
* QList implicitly converts to QVector, and vice versa
* These implicit conversions are marked as deprecated

Pros:
* Old (user) code doesn't silently change the meaning
* Old (user) code continues to work, lets users port at their own 
leisure
* Receiving objects can be done with auto variables for optimal 
performance

  or with QList for old code.
* Users passing QLists into Qt APIs enjoy the implicit conversion to 
QVector

  + This might be slow, but you say yourself that speed doesn't matter
for 95% of the code and it's easier to find and fix slow code in
the 5% than it is to find a silent reference stability breakage in
the 95%.

Cons:
* Unported code will get penalized by the implicit conversions from and 
to QList
  + But using the 95/5-argument here, again: it's easier to find where 
the app

got slower in the 5% than to find a bug in the 95%.

The pros far, far outweigh the cons. I'd very much like to know in which 
aspects inheriting QList from QVector fares better than this proposal.


My fear is that QList : QVector will lead to some of Qt's APIs 
continuing to use QList, which would lock Qt into QList for another 
major release cycle and only postpone the inevitable QList removal. 
C++11 gave us the tools to make this transition now much smoother than 
it could have been done in Qt 4->5. Inheriting QList from QVector is 
both technically wrong (value classes inheriting each other) and just 
serves to confuse users (is it still ok to use QList? Is it now suddenly 
ok after it wasn't in Qt 5? What do to if I target both Qt 5 and Qt 6?).


Touché on the QStringView reference :)

Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

That's not equal to directly discouraging the use of qlist. Especially
since they have different interfaces.
That's "blah blah blah, if you are interested in details blah blah blah"

I've read it, not everyone did, I am sure of it. And it's not equal to
directly stating: "if you continue using qlist you are going to have a bad
time (tm) come Qt6"


On Mon, May 20, 2019 at 3:02 PM Иван Комиссаров  wrote:

> https://doc.qt.io/qt-5/qlist.html#details
>
>
>- QVector  should be your default
>first choice. QVector  will
>usually give better performance than QList
>, because QVector
> always stores its items
>sequentially in memory, where QList 
>will allocate its items on the heap unless sizeof(T) <= sizeof(void*) and
>T has been declared to be either a Q_MOVABLE_TYPE or a Q_PRIMITIVE_TYPE
> using Q_DECLARE_TYPEINFO
>. See the Pros
>and Cons of Using QList
> 
> for
>an explanation.
>
>
> Иван Комиссаров
>
> 20 мая 2019 г., в 13:40, NIkolai Marchenko 
> написал(а):
>
> And on the matter of "you should have read all the discussions so you had
> years to port away from QList"
>
> I am sorry, what? QList was never indicated as deprecated or somehow
> undesirable in Qt docs far as I know and not every developer actively reads
> these topics.
> Moreover with all the discussions that were going on about "somehow saving
> the user the pain for Qt6" I am sure a lot of ppl who *knew* still didn't
> bother.
>
> This *really* is not something I expected being thrown around as a serious
> argument here.
>
> On Mon, May 20, 2019 at 2:18 PM NIkolai Marchenko 
> wrote:
>
>> I was speaking strictly of the cases where users already have auto used
>> in their code _expecting it to signify owning container_.
>> Imagine if they expect ownership in these cases. If the actual owning
>> container that exists somewhere else somehow goes out of scope
>> when the user expected to own it for a while (but declared it as auto)
>> you are introducing nasty bugs while maintaining SC.
>>
>> On Mon, May 20, 2019 at 12:35 PM Edward Welbourne 
>> wrote:
>>
>>> On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov 
>>> wrote:
>>> >>   If a user needs a regular container, range might be simply assigned
>>> to it.
>>>
>>> NIkolai Marchenko (16 May 2019 20:38) replied
>>> > It depends on what you expect the average usecase to be.
>>> > If we assume that a regular container is generally more used then you
>>> are preventing ppl from "almost always auto"
>>>
>>> First: I don't believe we've committed to "almost always auto" as a Qt
>>> coding style (it leaves the reader to work out what everything is, which
>>> I - as a reviewer - really don't like).  Being explicit about what type
>>> of container you want to use has its virtues (albeit, as Marc points
>>> out, auto's ambiguity is good when the API is in flux).
>>>
>>> Second: if we return a container, the API designer has to decide which
>>> type of container to return, which forces the caller to do a conversion
>>> if that wasn't the type they wanted.  Returning a range lets the caller
>>> chose how to store the values.
>>>
>>> However, that's only a win if the supplier wasn't already holding the
>>> values in a container, which CoW lets us return cheaply.
>>>
>>> The win (assuming C++ ranges work enough like python generators) comes
>>> when you're traversing some population of things and selecting some to
>>> return, while skipping the rest; classically that might be implemented
>>> as a traversal with a call-back object to act on each item; but a range
>>> lets the caller just iterate over the results found, turning the
>>> call-back's code into a loop's body, which is far easier to follow; or
>>> collecting the results into a container of the caller's choosing.
>>>
>>> Eddy.
>>>
>> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Иван Комиссаров]

https://doc.qt.io/qt-5/qlist.html#details

QVector should be your default first choice. QVector will usually give 
better performance than QList, because QVector always stores its items 
sequentially in memory, where QList will allocate its items on the heap 
unless sizeof(T) <= sizeof(void*) and T has been declared to be either a 
Q_MOVABLE_TYPE or a Q_PRIMITIVE_TYPE using Q_DECLARE_TYPEINFO. See the Pros and 
Cons of Using QList for an explanation.

Иван Комиссаров

> 20 мая 2019 г., в 13:40, NIkolai Marchenko  
> написал(а):
> 
> And on the matter of "you should have read all the discussions so you had 
> years to port away from QList"
> 
> I am sorry, what? QList was never indicated as deprecated or somehow 
> undesirable in Qt docs far as I know and not every developer actively reads 
> these topics.
> Moreover with all the discussions that were going on about "somehow saving 
> the user the pain for Qt6" I am sure a lot of ppl who *knew* still didn't 
> bother.
> 
> This *really* is not something I expected being thrown around as a serious 
> argument here.
> 
>> On Mon, May 20, 2019 at 2:18 PM NIkolai Marchenko  
>> wrote:
>> I was speaking strictly of the cases where users already have auto used in 
>> their code _expecting it to signify owning container_.
>> Imagine if they expect ownership in these cases. If the actual owning 
>> container that exists somewhere else somehow goes out of scope 
>> when the user expected to own it for a while (but declared it as auto) you 
>> are introducing nasty bugs while maintaining SC.
>> 
>>> On Mon, May 20, 2019 at 12:35 PM Edward Welbourne  
>>> wrote:
>>> On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov  
>>> wrote:
>>> >>   If a user needs a regular container, range might be simply assigned to 
>>> >> it.
>>> 
>>> NIkolai Marchenko (16 May 2019 20:38) replied
>>> > It depends on what you expect the average usecase to be.
>>> > If we assume that a regular container is generally more used then you are 
>>> > preventing ppl from "almost always auto"
>>> 
>>> First: I don't believe we've committed to "almost always auto" as a Qt
>>> coding style (it leaves the reader to work out what everything is, which
>>> I - as a reviewer - really don't like).  Being explicit about what type
>>> of container you want to use has its virtues (albeit, as Marc points
>>> out, auto's ambiguity is good when the API is in flux).
>>> 
>>> Second: if we return a container, the API designer has to decide which
>>> type of container to return, which forces the caller to do a conversion
>>> if that wasn't the type they wanted.  Returning a range lets the caller
>>> chose how to store the values.
>>> 
>>> However, that's only a win if the supplier wasn't already holding the
>>> values in a container, which CoW lets us return cheaply.
>>> 
>>> The win (assuming C++ ranges work enough like python generators) comes
>>> when you're traversing some population of things and selecting some to
>>> return, while skipping the rest; classically that might be implemented
>>> as a traversal with a call-back object to act on each item; but a range
>>> lets the caller just iterate over the results found, turning the
>>> call-back's code into a loop's body, which is far easier to follow; or
>>> collecting the results into a container of the caller's choosing.
>>> 
>>> Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

And on the matter of "you should have read all the discussions so you had
years to port away from QList"

I am sorry, what? QList was never indicated as deprecated or somehow
undesirable in Qt docs far as I know and not every developer actively reads
these topics.
Moreover with all the discussions that were going on about "somehow saving
the user the pain for Qt6" I am sure a lot of ppl who *knew* still didn't
bother.

This *really* is not something I expected being thrown around as a serious
argument here.

On Mon, May 20, 2019 at 2:18 PM NIkolai Marchenko 
wrote:

> I was speaking strictly of the cases where users already have auto used in
> their code _expecting it to signify owning container_.
> Imagine if they expect ownership in these cases. If the actual owning
> container that exists somewhere else somehow goes out of scope
> when the user expected to own it for a while (but declared it as auto) you
> are introducing nasty bugs while maintaining SC.
>
> On Mon, May 20, 2019 at 12:35 PM Edward Welbourne 
> wrote:
>
>> On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov 
>> wrote:
>> >>   If a user needs a regular container, range might be simply assigned
>> to it.
>>
>> NIkolai Marchenko (16 May 2019 20:38) replied
>> > It depends on what you expect the average usecase to be.
>> > If we assume that a regular container is generally more used then you
>> are preventing ppl from "almost always auto"
>>
>> First: I don't believe we've committed to "almost always auto" as a Qt
>> coding style (it leaves the reader to work out what everything is, which
>> I - as a reviewer - really don't like).  Being explicit about what type
>> of container you want to use has its virtues (albeit, as Marc points
>> out, auto's ambiguity is good when the API is in flux).
>>
>> Second: if we return a container, the API designer has to decide which
>> type of container to return, which forces the caller to do a conversion
>> if that wasn't the type they wanted.  Returning a range lets the caller
>> chose how to store the values.
>>
>> However, that's only a win if the supplier wasn't already holding the
>> values in a container, which CoW lets us return cheaply.
>>
>> The win (assuming C++ ranges work enough like python generators) comes
>> when you're traversing some population of things and selecting some to
>> return, while skipping the rest; classically that might be implemented
>> as a traversal with a call-back object to act on each item; but a range
>> lets the caller just iterate over the results found, turning the
>> call-back's code into a loop's body, which is far easier to follow; or
>> collecting the results into a container of the caller's choosing.
>>
>> Eddy.
>>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

I was speaking strictly of the cases where users already have auto used in
their code _expecting it to signify owning container_.
Imagine if they expect ownership in these cases. If the actual owning
container that exists somewhere else somehow goes out of scope
when the user expected to own it for a while (but declared it as auto) you
are introducing nasty bugs while maintaining SC.

On Mon, May 20, 2019 at 12:35 PM Edward Welbourne 
wrote:

> On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov 
> wrote:
> >>   If a user needs a regular container, range might be simply assigned
> to it.
>
> NIkolai Marchenko (16 May 2019 20:38) replied
> > It depends on what you expect the average usecase to be.
> > If we assume that a regular container is generally more used then you
> are preventing ppl from "almost always auto"
>
> First: I don't believe we've committed to "almost always auto" as a Qt
> coding style (it leaves the reader to work out what everything is, which
> I - as a reviewer - really don't like).  Being explicit about what type
> of container you want to use has its virtues (albeit, as Marc points
> out, auto's ambiguity is good when the API is in flux).
>
> Second: if we return a container, the API designer has to decide which
> type of container to return, which forces the caller to do a conversion
> if that wasn't the type they wanted.  Returning a range lets the caller
> chose how to store the values.
>
> However, that's only a win if the supplier wasn't already holding the
> values in a container, which CoW lets us return cheaply.
>
> The win (assuming C++ ranges work enough like python generators) comes
> when you're traversing some population of things and selecting some to
> return, while skipping the rest; classically that might be implemented
> as a traversal with a call-back object to act on each item; but a range
> lets the caller just iterate over the results found, turning the
> call-back's code into a loop's body, which is far easier to follow; or
> collecting the results into a container of the caller's choosing.
>
> Eddy.
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Lars Knoll]

Hi Marc,

> On 16 May 2019, at 15:05, Mutz, Marc via Development 
>  wrote:
> 
> Hi Lars,
> 
> On 2018-11-02 08:51, Lars Knoll wrote:
>> I believe I have a solution to get rid of QList without breaking SC in
>> any major way. See https://codereview.qt-project.org/#/c/242199/ and
>> the following changes.
> [...]
>> So to re-iterate: We will not break SC in major ways. The goal is to
>> make porting from Qt 5.x to 6 as easy as possible.
> 
> It's technically SC alright, but silently breaking the reference stability 
> user code may rely on should be a complete no-no, considering how reluctant 
> Qt has been since the Qt 3->4 port with disruptive changes. I welcome the 
> openness to rethink the necessity of some of the plumbing infrastructure, but 
> it appears that you have come out far on the other side on this one.

I don’t think so. At least not if we provide a fully compatible QList in e.g. a 
Qt5Support module/namespace, and allowing the app to use it with a simple 
switch.
> 
> As I said a few years ago, QList in Qt 5 should have a warning if it keeps 
> reference stability (iow: if it's not already behaviour- if not 
> structure-compatible with QVector), indicting very strongly that by Qt 6, 
> this use-case will be gone. Then port all of Qt's own code away from QList, 
> either to QVector, or, say, std::vector, like in QToolBox 
> (https://codereview.qt-project.org/261943), which is a case where a user that 
> actually relies on the implicit reference-stability guarantee of current 
> QList, then deprecate QList.

This is our job now for 5.14/5.15. Make sure we add warnings for all use cases 
we don’t want to support in Qt 6 anymore. The problem with stability of those 
references is that it’s unfortunately rather hard to have them detected by the 
compiler.

Having said that, this is the only major source breakage, and it’s a relatively 
uncommon one. In addition, a build with address sanitiser enabled should 
quickly find those, so I don’t think it’s something we need to keep by default 
until everybody manually changed all their code to use QVector.

> 
> Back then I suggested to rename QList to QArrayList and have QList be a 
> deprecated template alias for _either_ QArrayList or QVector, depending on 
> whether Q5List would keep references stable or not.

That would be more source compatible. But I would really not want to continue 
to return and take QLists in our public APIs. And if we don’t do that Qt6 will 
basically incur a copy between (un-ported) user code and Qt code. The question 
is whether not having that overhead is more important than reference stability 
or not.
> 
> Please don't make QList an unconditional alias for QVector. You are silently 
> breaking Qt code (cf. QToolBox) along with an unknown amount of Qt-user's 
> code. Make the break non-silent.
> 
> I understand the desire to keep old code working that was written against Qt 
> 5. But to me, the better solution would be to have the Qt 6 API explicitly 
> return QVector and have implicit, but deprecated, conversions between QList 
> and QVector. The priority should be to not break code. It should not be a 
> priority to have unported code enjoy optimal speed. An actual copy on 
> implicit QVector -> QList conversion is acceptable, IMO, since the solution 
> for codebases targeting both Qt 5 and 6 is simple: use an auto variable.

Auto doesn’t always work. It works for return values, but it won’t work for 
objects the user creates and wants to pass into Qt API.

Another option (outlined above) could be a compile switch between your idea 
(fully SC, but performance penalty) and mine (slightly SIC, but no performance 
penalty). Users could then choose which way they want to go.
> 
> Going forward, we should be looking into removing more and more owning 
> containers from the interface and replace them with views. The standard is 
> working on a solution for the stale reference problem, and by the time Qt 7 
> comes around, it will be hopefully widely available.

Let’s keep that discussion separate. But if we’re going on that tangent, we 
should at least finish the QStringView related work for Qt 6.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Edward Welbourne]

On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov  wrote:
>>   If a user needs a regular container, range might be simply assigned to it.

NIkolai Marchenko (16 May 2019 20:38) replied
> It depends on what you expect the average usecase to be.
> If we assume that a regular container is generally more used then you are 
> preventing ppl from "almost always auto"

First: I don't believe we've committed to "almost always auto" as a Qt
coding style (it leaves the reader to work out what everything is, which
I - as a reviewer - really don't like).  Being explicit about what type
of container you want to use has its virtues (albeit, as Marc points
out, auto's ambiguity is good when the API is in flux).

Second: if we return a container, the API designer has to decide which
type of container to return, which forces the caller to do a conversion
if that wasn't the type they wanted.  Returning a range lets the caller
chose how to store the values.

However, that's only a win if the supplier wasn't already holding the
values in a container, which CoW lets us return cheaply.

The win (assuming C++ ranges work enough like python generators) comes
when you're traversing some population of things and selecting some to
return, while skipping the rest; classically that might be implemented
as a traversal with a call-back object to act on each item; but a range
lets the caller just iterate over the results found, turning the
call-back's code into a loop's body, which is far easier to follow; or
collecting the results into a container of the caller's choosing.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[NIkolai Marchenko]

>   If a user needs a regular container, range might be simply assigned to
it.
It depends on what you expect the average usecase to be.
If we assume that a regular container is generally more used then you are
preventing ppl from "almost always auto"

On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov 
wrote:

> Going forward, we should be looking into removing more and more owning
> containers from the interface and replace them with views. The standard is
> working on a solution for the stale reference problem, and by the time Qt 7
> comes around, it will be hopefully widely available.
>
>
> This is good direction. But I would suggest something based on ranges
> (accepted for C++ 20 and there is already ranges-v3 on github or ranges in
> boost). What we should return in our API is lazy range object. This is
> actually a sort of view or chain of nested views with some conditions. If a
> user needs a regular container, range might be simply assigned to it.
>
> --
> Best Regards,
>
> Fanaskov Vitaly
> Senior Software Engineer
>
> The Qt Company / Qt Quick and Widgets Team
>
> On 16 May 2019, at 15:05, Mutz, Marc via Development <
> development@qt-project.org> wrote:
>
> Hi Lars,
>
> On 2018-11-02 08:51, Lars Knoll wrote:
>
> I believe I have a solution to get rid of QList without breaking SC in
> any major way. See https://codereview.qt-project.org/#/c/242199/ and
> the following changes.
>
> [...]
>
> So to re-iterate: We will not break SC in major ways. The goal is to
> make porting from Qt 5.x to 6 as easy as possible.
>
>
> It's technically SC alright, but silently breaking the reference stability
> user code may rely on should be a complete no-no, considering how reluctant
> Qt has been since the Qt 3->4 port with disruptive changes. I welcome the
> openness to rethink the necessity of some of the plumbing infrastructure,
> but it appears that you have come out far on the other side on this one.
>
> As I said a few years ago, QList in Qt 5 should have a warning if it keeps
> reference stability (iow: if it's not already behaviour- if not
> structure-compatible with QVector), indicting very strongly that by Qt 6,
> this use-case will be gone. Then port all of Qt's own code away from QList,
> either to QVector, or, say, std::vector, like in QToolBox (
> https://codereview.qt-project.org/261943), which is a case where a user
> that actually relies on the implicit reference-stability guarantee of
> current QList, then deprecate QList.
>
> Back then I suggested to rename QList to QArrayList and have QList be a
> deprecated template alias for _either_ QArrayList or QVector, depending on
> whether Q5List would keep references stable or not.
>
> Please don't make QList an unconditional alias for QVector. You are
> silently breaking Qt code (cf. QToolBox) along with an unknown amount of
> Qt-user's code. Make the break non-silent.
>
> I understand the desire to keep old code working that was written against
> Qt 5. But to me, the better solution would be to have the Qt 6 API
> explicitly return QVector and have implicit, but deprecated, conversions
> between QList and QVector. The priority should be to not break code. It
> should not be a priority to have unported code enjoy optimal speed. An
> actual copy on implicit QVector -> QList conversion is acceptable, IMO,
> since the solution for codebases targeting both Qt 5 and 6 is simple: use
> an auto variable.
>
> Going forward, we should be looking into removing more and more owning
> containers from the interface and replace them with views. The standard is
> working on a solution for the stale reference problem, and by the time Qt 7
> comes around, it will be hopefully widely available.
>
> Thanks for considering,
> Marc
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Vitaly Fanaskov]

Going forward, we should be looking into removing more and more owning 
containers from the interface and replace them with views. The standard is 
working on a solution for the stale reference problem, and by the time Qt 7 
comes around, it will be hopefully widely available.

This is good direction. But I would suggest something based on ranges (accepted 
for C++ 20 and there is already ranges-v3 on github or ranges in boost). What 
we should return in our API is lazy range object. This is actually a sort of 
view or chain of nested views with some conditions. If a user needs a regular 
container, range might be simply assigned to it.

--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

On 16 May 2019, at 15:05, Mutz, Marc via Development 
mailto:development@qt-project.org>> wrote:

Hi Lars,

On 2018-11-02 08:51, Lars Knoll wrote:
I believe I have a solution to get rid of QList without breaking SC in
any major way. See https://codereview.qt-project.org/#/c/242199/ and
the following changes.
[...]
So to re-iterate: We will not break SC in major ways. The goal is to
make porting from Qt 5.x to 6 as easy as possible.

It's technically SC alright, but silently breaking the reference stability user 
code may rely on should be a complete no-no, considering how reluctant Qt has 
been since the Qt 3->4 port with disruptive changes. I welcome the openness to 
rethink the necessity of some of the plumbing infrastructure, but it appears 
that you have come out far on the other side on this one.

As I said a few years ago, QList in Qt 5 should have a warning if it keeps 
reference stability (iow: if it's not already behaviour- if not 
structure-compatible with QVector), indicting very strongly that by Qt 6, this 
use-case will be gone. Then port all of Qt's own code away from QList, either 
to QVector, or, say, std::vector, like in QToolBox 
(https://codereview.qt-project.org/261943), which is a case where a user that 
actually relies on the implicit reference-stability guarantee of current QList, 
then deprecate QList.

Back then I suggested to rename QList to QArrayList and have QList be a 
deprecated template alias for _either_ QArrayList or QVector, depending on 
whether Q5List would keep references stable or not.

Please don't make QList an unconditional alias for QVector. You are silently 
breaking Qt code (cf. QToolBox) along with an unknown amount of Qt-user's code. 
Make the break non-silent.

I understand the desire to keep old code working that was written against Qt 5. 
But to me, the better solution would be to have the Qt 6 API explicitly return 
QVector and have implicit, but deprecated, conversions between QList and 
QVector. The priority should be to not break code. It should not be a priority 
to have unported code enjoy optimal speed. An actual copy on implicit QVector 
-> QList conversion is acceptable, IMO, since the solution for codebases 
targeting both Qt 5 and 6 is simple: use an auto variable.

Going forward, we should be looking into removing more and more owning 
containers from the interface and replace them with views. The standard is 
working on a solution for the stale reference problem, and by the time Qt 7 
comes around, it will be hopefully widely available.

Thanks for considering,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Thiago Macieira]

On Thursday, 16 May 2019 06:05:37 PDT Mutz, Marc via Development wrote:
> Going forward, we should be looking into removing more and more owning
> containers from the interface and replace them with views. The standard
> is working on a solution for the stale reference problem, and by the
> time Qt 7 comes around, it will be hopefully widely available.

That goes against the Qt API design. Do not return views, since it implies 
that internally there is an object that produces that view and that it does 
not go out of scope. The reason we return full, owning containers is so we 
have the freedom inside to change how we store the data without that affecting 
our API.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6

[Mutz, Marc via Development]

Hi Lars,

On 2018-11-02 08:51, Lars Knoll wrote:

I believe I have a solution to get rid of QList without breaking SC in
any major way. See https://codereview.qt-project.org/#/c/242199/ and
the following changes.

[...]

So to re-iterate: We will not break SC in major ways. The goal is to
make porting from Qt 5.x to 6 as easy as possible.


It's technically SC alright, but silently breaking the reference 
stability user code may rely on should be a complete no-no, considering 
how reluctant Qt has been since the Qt 3->4 port with disruptive 
changes. I welcome the openness to rethink the necessity of some of the 
plumbing infrastructure, but it appears that you have come out far on 
the other side on this one.


As I said a few years ago, QList in Qt 5 should have a warning if it 
keeps reference stability (iow: if it's not already behaviour- if not 
structure-compatible with QVector), indicting very strongly that by Qt 
6, this use-case will be gone. Then port all of Qt's own code away from 
QList, either to QVector, or, say, std::vector, like in 
QToolBox (https://codereview.qt-project.org/261943), which is a case 
where a user that actually relies on the implicit reference-stability 
guarantee of current QList, then deprecate QList.


Back then I suggested to rename QList to QArrayList and have QList be a 
deprecated template alias for _either_ QArrayList or QVector, depending 
on whether Q5List would keep references stable or not.


Please don't make QList an unconditional alias for QVector. You are 
silently breaking Qt code (cf. QToolBox) along with an unknown amount of 
Qt-user's code. Make the break non-silent.


I understand the desire to keep old code working that was written 
against Qt 5. But to me, the better solution would be to have the Qt 6 
API explicitly return QVector and have implicit, but deprecated, 
conversions between QList and QVector. The priority should be to not 
break code. It should not be a priority to have unported code enjoy 
optimal speed. An actual copy on implicit QVector -> QList conversion is 
acceptable, IMO, since the solution for codebases targeting both Qt 5 
and 6 is simple: use an auto variable.


Going forward, we should be looking into removing more and more owning 
containers from the interface and replace them with views. The standard 
is working on a solution for the stale reference problem, and by the 
time Qt 7 comes around, it will be hopefully widely available.


Thanks for considering,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QList for Qt 6 (was: Re: Build system for Qt 6)

[Lars Knoll]

On 2 Nov 2018, at 09:04, Philippe 
mailto:philw...@gmail.com>> wrote:

I did some benchmarking (as we were worried about the different performance 
characteristics of QList and QVector) and with the exception of prepending in a 
loop pretty much all other operations gets faster with this change.

Another exception is certainly the sorting of large objects that are not 
implicit-shared classes.

True. But for 99% of the cases where QList is being used today performance 
would probably increase when using a vector instead. That’s especially true 
when you have objects that are larger than a pointer.

Ok anyway. But keeping the old QList under a new name, cannot harm.

Sure, we can have a Q5List around in Qt 6 times, or people could simply copy 
the code if they need it.

Much of Qt was built with QList, so QList can't be that bad ;)

That conclusion doesn’t have to be true. But yes, QList was ok, because most of 
what we put into it were implicitly shared classes. But a QList is 
actually a very bad idea (just to give one example).

Cheers,
Lars


Philippe

On Fri, 2 Nov 2018 07:51:22 +
Lars Knoll mailto:lars.kn...@qt.io>> wrote:

Renaming the subthread (it’s got nothing to do with build systems…)

I believe I have a solution to get rid of QList without breaking SC in any 
major way. See https://codereview.qt-project.org/#/c/242199/ and the following 
changes.

I did some benchmarking (as we were worried about the different performance 
characteristics of QList and QVector) and with the exception of prepending in a 
loop pretty much all other operations gets faster with this change.

So to re-iterate: We will not break SC in major ways. The goal is to make 
porting from Qt 5.x to 6 as easy as possible.

Cheers,
Lars

On 30 Oct 2018, at 20:21, NIkolai Marchenko 
mailto:enmarantis...@gmail.com>> wrote:

>  No, we will break source compatibility in a minor way.

I am not aware of what was the end result of QList discussion, but didn't you 
want to deprecate/majorly change that at some point?
That alone would be rather huge.

On Tue, Oct 30, 2018 at 10:19 PM Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:
On Tuesday, 30 October 2018 12:11:38 PDT NIkolai Marchenko wrote:
>  >  That's not going to happen any more than our breaking source
>
> compatibility in
> a major way.
>
> You are breaking source compatibility in a major way with Qt6 ... ;)

No, we will break source compatibility in a minor way.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList for Qt 6 (was: Re: Build system for Qt 6)

[Philippe]

I did some benchmarking (as we were worried about the different performance 
characteristics of QList and QVector) and with the exception of prepending in a 
loop pretty much all other operations gets faster with this change.

Another exception is certainly the sorting of large objects that are not 
implicit-shared classes.

Ok anyway. But keeping the old QList under a new name, cannot harm.

Much of Qt was built with QList, so QList can't be that bad ;)


Philippe

On Fri, 2 Nov 2018 07:51:22 +
Lars Knoll  wrote:

Renaming the subthread (it’s got nothing to do with build systems…) 
> 
> 
> I believe I have a solution to get rid of QList without breaking SC in any 
> major way. See https://codereview.qt-project.org/#/c/242199/ and the 
> following changes.
> 
> 
> I did some benchmarking (as we were worried about the different performance 
> characteristics of QList and QVector) and with the exception of prepending in 
> a loop pretty much all other operations gets faster with this change.
> 
> 
> So to re-iterate: We will not break SC in major ways. The goal is to make 
> porting from Qt 5.x to 6 as easy as possible.
> 
> 
> Cheers,
> Lars
> 
>> On 30 Oct 2018, at 20:21, NIkolai Marchenko  wrote:
>> 
>> >  No, we will break source compatibility in a minor way. 
>> 
>> 
>> I am not aware of what was the end result of QList discussion, but didn't 
>> you want to deprecate/majorly change that at some point?
>> That alone would be rather huge.
>> 
>> 
>> On Tue, Oct 30, 2018 at 10:19 PM Thiago Macieira  
>> wrote:
>> 
>> On Tuesday, 30 October 2018 12:11:38 PDT NIkolai Marchenko wrote:
>>> >  >  That's not going to happen any more than our breaking source
>>> > 
>>> > compatibility in
>>> > a major way.
>>> > 
>>> > You are breaking source compatibility in a major way with Qt6 ... ;)
>>> 
>>> No, we will break source compatibility in a minor way.
>>> 
>>> -- 
>>> Thiago Macieira - thiago.macieira (AT) intel.com
>>>   Software Architect - Intel Open Source Technology Center
>>> 
>>> 
>>> 
>>> ___
>>> Development mailing list
>>> Development@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development





___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QList for Qt 6 (was: Re: Build system for Qt 6)

[Lars Knoll]

Renaming the subthread (it’s got nothing to do with build systems…)

I believe I have a solution to get rid of QList without breaking SC in any 
major way. See https://codereview.qt-project.org/#/c/242199/ and the following 
changes.

I did some benchmarking (as we were worried about the different performance 
characteristics of QList and QVector) and with the exception of prepending in a 
loop pretty much all other operations gets faster with this change.

So to re-iterate: We will not break SC in major ways. The goal is to make 
porting from Qt 5.x to 6 as easy as possible.

Cheers,
Lars

On 30 Oct 2018, at 20:21, NIkolai Marchenko 
mailto:enmarantis...@gmail.com>> wrote:

>  No, we will break source compatibility in a minor way.

I am not aware of what was the end result of QList discussion, but didn't you 
want to deprecate/majorly change that at some point?
That alone would be rather huge.

On Tue, Oct 30, 2018 at 10:19 PM Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:
On Tuesday, 30 October 2018 12:11:38 PDT NIkolai Marchenko wrote:
>  >  That's not going to happen any more than our breaking source
>
> compatibility in
> a major way.
>
> You are breaking source compatibility in a major way with Qt6 ... ;)

No, we will break source compatibility in a minor way.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development