[Development] Proposal: Deprecate QVector in Qt 6

[Jason H]

> Sent: Friday, April 24, 2020 at 4:14 PM
> From: "Giuseppe D'Angelo" <giuseppe.dangelo at kdab.com>
> To: "Jason H" <jhihn at gmx.com>
> Cc: development at 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.