Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

(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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

> 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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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 |

Re: [Development] QList for Qt 6

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:

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

> 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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

> 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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

> 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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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?

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

> 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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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,

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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>

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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 f

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

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

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

Re: [Development] QList for Qt 6

> 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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

> 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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

Re: [Development] QList for Qt 6

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

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

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.

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

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

Re: [Development] QList

Hi, Op 29/05/2017 om 14:53 schreef Jason H: >> Sent: Thursday, May 25, 2017 at 7:03 PM >> From: "André Somers" <an...@familiesomers.nl> >> To: "Christoph Feck" <cf...@kde.org> >> Cc: development@qt-project.org >> Subject: Re

Re: [Development] QList

> Sent: Thursday, May 25, 2017 at 7:03 PM > From: "André Somers" <an...@familiesomers.nl> > To: "Christoph Feck" <cf...@kde.org> > Cc: development@qt-project.org > Subject: Re: [Development] QList > > Hi, > > Sent from my phone, please e

Re: [Development] QList

On Thursday 25 May 2017 18:40:46 Christoph Feck wrote: > If you only return a view to the container, then if the container is > modified, the return value is no longer valid. Returning a full > container (referenced, with copy-on-write semantics) will not have this > problem. If you return a

Re: [Development] QList

On 25.05.2017 19:03, André Somers wrote: On 25 May 2017, at 18:40, Christoph Feck wrote: On 25.05.2017 13:53, André Somers wrote: Op 25/05/2017 om 12:38 schreef Konstantin Tokarev: Other problem, that IMO is more serious, is that Qt *requires* user to use QList, by returning

Re: [Development] QList

Hi, Sent from my phone, please excuse my brevity > On 25 May 2017, at 18:40, Christoph Feck wrote: > >> On 25.05.2017 13:53, André Somers wrote: >> Op 25/05/2017 om 12:38 schreef Konstantin Tokarev: >>> Other problem, that IMO is more serious, is that Qt *requires* user to use

Re: [Development] QList

On 25.05.2017 13:53, André Somers wrote: Op 25/05/2017 om 12:38 schreef Konstantin Tokarev: Other problem, that IMO is more serious, is that Qt *requires* user to use QList, by returning or taking it as and argument in various places. That's almost only reason why I use QList in my code[*].

Re: [Development] QList

Op 25/05/2017 om 12:38 schreef Konstantin Tokarev: > > 25.05.2017, 02:19, "Ville Voutilainen" : >> On 24 May 2017 at 22:25, Marc Mutz wrote: >>> On 2017-05-24 15:12, Konstantin Tokarev wrote: 24.05.2017, 15:49, "NIkolai Marchenko"

Re: [Development] QList

25.05.2017, 02:19, "Ville Voutilainen" : > On 24 May 2017 at 22:25, Marc Mutz wrote: >>  On 2017-05-24 15:12, Konstantin Tokarev wrote: >>>  24.05.2017, 15:49, "NIkolai Marchenko" :  A semi-sane idea that I think no

Re: [Development] QList

On 2017-05-25 01:19, Ville Voutilainen wrote: [...] How does it help anyone to create a new alias that still results in a concrete type the semantics of which still depend on the element type? The QList type alias in Qt 6 would be deprecated from the get-go. As would be the QArrayList/QVector

Re: [Development] QList

On 24 May 2017 at 22:25, Marc Mutz wrote: > On 2017-05-24 15:12, Konstantin Tokarev wrote: >> >> 24.05.2017, 15:49, "NIkolai Marchenko" : >>> >>> A semi-sane idea that I think no one has suggested yet: >>> >>> What if, starting from Qt6, QList becomes

Re: [Development] QList

On 2017-05-24 15:12, Konstantin Tokarev wrote: 24.05.2017, 15:49, "NIkolai Marchenko" : A semi-sane idea that I think no one has suggested yet: What if, starting from Qt6, QList becomes a wrapper for QArrayList with a contructor from this type? After all making

Re: [Development] QList

Not necessarily. It really depends on which type Qt decides to use in place of what is now returned as a QList. As far as wrapper is concerned, it doesn't even need to be a singlular type if the interface matches since it will be a template anyway. P.S. I am not really involved with Qt

  1   2   3   4   >