> Sent: Friday, April 24, 2020 at 4:14 PM > From: "Giuseppe D'Angelo" <giuseppe.dang...@kdab.com> > To: "Jason H" <jh...@gmx.com> > Cc: development@qt-project.org > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 > > On 4/24/20 9:03 PM, Jason H wrote: > >> In fact, it is-a QList<QString>. What's the problem here with its naming? > > > > Because I can't QSringList{"me", "you"}.join() with a QList. > > I didn't say that it's a typedef for QList<QString>, but is-a -- it > inherits, precisely to provide that kind of convenience. > > > Thinking outsize of the box... > > It seems that all this is cause d by someone wanting to store a pointer to > > an item in QVector, which may be reallocted and therfore have moved. > > All this => what's this? > > > It seem then that the only thing to do is to use a traditional QList, or > > return only some kind of ref which will be a stable reference to the item. > > QStableRef r9 = vector[9]; > > vector.resize() > > // r9 is updated during resize() and still points to that it was meant to. > > It's not good practice to store a ref to something that can be realloated. > > I don't know how you can prevent people from doing that with offering T& > > operator[](int i); > > QList today offers exactly that. In array-of-pointers-mode it also > offers stability of references.
Yes. I agree. I think the OP kicked this off with a thing about soring refs to items in QVector which is relocatable. My post was just to say this is a bad idea fro QVector. This is not immediately obvious though. The API/docs fail to communicate that storing pointers/refs to items is a bad idea. Which then as me agree with you and Lars's current thinking. I however want some generic indexable/iterable type, where it doesn't care if the final storage is QList or QVector... When I am working as an API, I don't want to choose for my users what that type is and make them pay for conversion. Which I think QList was historically the right choice. Ideally I want to have a QIterable for processing lists/arrays/vectors. I think the developer should be able to determine the storage best for their application, not me. Side note: It also kicked off a thing in my brain about .NET and the managed runtime, where C++ on .NET got ^, the handle operator, which allows dereferencing to items given that everything is relocatable due to memory compaction. I think it could be a great thing if C++ has such a thing, as I attribute 99% of all long boot time lockups on Raspberry Pis to memory fragmentation (completely anecdotally) And if C/C+ could offer some kind of memory management beyond malloc/free, we could get the next 99% of lockups and random crashes avoided. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development