Reference stability in QVector/QList

JonB

[EDIT: Forked from https://forum.qt.io/topic/121963/random-crash-with-qvector/ --JKSH]

Purely OOI, if the OP changed to QList<int> data, does Qt implementation guarantee that int* p = &data[0]; stays pointing to that the data which was stored there (I realize it may no longer be the 0th element over time if inserts, but it will still be in the list), unlike for a QVector whose data may get moved?

J.Hilk

@JonB QList is very complicated, and I#m not fully in the topic, but in essence it has 2 modi either as a continuous array like a vector or as indeed the normal list implementation

But is only holds true in Qt5 and earlier. in Qt6 QList and QVector are the same, and IIRC it's now always guaranteed to be a continuous memory chunk.

I may be wrong here, I didn't follow the whole topic on QVecter Vs QList

Christian Ehrlicher

@JonB said in Random crash with QVector:

Purely OOI, if the OP changed to QList<int> data, does Qt implementation guarantee that int* p = &data[0]; stays pointing to that the data which was stored there

No, as soon as there is a re-allocate (same goes with QVector, std::vector, std::queue, ...) - yu must not store pointers to a container over a longer time.

JonB

@Christian-Ehrlicher
So if you stored a fair-sized struct (not struct *!) as your elements in a QList, as you appended new elements you would indeed be liable to all the existing elements getting moved in memory?

Christian Ehrlicher

@JonB said in Random crash with QVector:

you would indeed be liable to all the existing elements getting moved in memory?

Yes, but as I already wrote - nothing Qt specific. It's the nature of every container with a contiguous memory layout.

JonB

@Christian-Ehrlicher
Yes, but unlike you, I do not expect contiguous memory for a list, that's why I use a list :) You might [have that expectation], I don't.

Christian Ehrlicher

@JonB said in Random crash with QVector:

that's why I use a list

QList is no std::list (And I still don't understand why now QVector was killed in favor of QList in Qt6... but that's another topic)

kshegunov

@JonB said in Random crash with QVector:

Purely OOI, if the OP changed to QList<int> data, does Qt implementation guarantee that int* p = &data[0]; stays pointing to that the data which was stored there (I realize it may no longer be the 0th element over time if inserts, but it will still be in the list), unlike for a QVector whose data may get moved?

Not for int and Qt6, in Qt5 for types where sizeof(T) > sizeof(void *) you get reference stability, however even then that's not how one exploits it - rather you'd get a pointer/reference to the object itself, and work on that, not a pointer to the list/index w/e.

Anyway, that's finicky and a bad idea to begin with. If one wants to enforce the reference stability you either go with a linked list std::list, or simply store an array of pointers in the QVector/QList, then you're explicit and reordering of the pointers doesn't change the object's addresses themselves.

JonB

@Christian-Ehrlicher said in Random crash with QVector:

QList is no std::list

Precisely! Hence expectations may differ.

(And I still don't understand why now QVector was killed in favor of QList in Qt6

Nor I. Except that if QList<> is contiguous one can see how close they may be.

kshegunov

@Christian-Ehrlicher said in Random crash with QVector:

And I still don't understand why now QVector was killed in favor of QList in Qt6... but that's another topic

I liked QList and having the two minor optimizations it provided, but to leverage that one needs to be educated. I suppose no one wanted to spread the knowledge enough, so it got axed instead.

Christian Ehrlicher

@kshegunov said in Random crash with QVector:

so it got axed instead.

That's the problem - it's not. A well defined QVector was replaced with a QList which creates a lot of confusions with std::list - this was just stupid and will create a lot of questions in the near future here.

coffeesmoke

@J-Hilk Hi.
With the development of c++ and the inclusion of STL in the standard, I think the use of classes like QVector is left for compatibility. When developing, I use std::vector. To interact within the Qt Framework, I use QVector<T> QVector::fromStdVector(const std::vector<T> &vector).
This approach makes it possible to drill down classes into inheritors of QObject with Q_OBJECT macros (b tail of moc_* files) and c++ classes of standard 11 and higher with STL containers.

J.Hilk

@coffeesmoke I'm not a fan of snake_case, so I try to stay away from the standard, if I can 😉

JonB

@coffeesmoke said in Reference stability in QVector/QList:

QVector::fromStdVector

Doesn't this (and for that matter toStdVector() too) do a copy?

Separately, I note in https://doc.qt.io/qt-5/qvector.html#fromStdVector (for toVector() too)

Note: Since Qt 5.14, range constructors are available for Qt's generic container classes and should be used in place of this method.

coffeesmoke

@JonB yes, this is a copying method. i rarely use this, for example, to pass a copy of data to UI-classes.
All business logic is implemented on STL often in private sections of code. Perhaps working with the QVector class ... maybe you won't need it: stl is enough::vector.

Here you need to look at the task and choose. I apologize for the long speech. :)

JKSH

@J-Hilk said in Reference stability in QVector/QList:

in Qt6 QList and QVector are the same, and IIRC it's now always guaranteed to be a continuous memory chunk.

That's correct. In Qt 6, QList and QVector are different names for the same class, and that class is the Qt version of std::vector.

@coffeesmoke said in Reference stability in QVector/QList:

With the development of c++ and the inclusion of STL in the standard, I think the use of classes like QVector is left for compatibility.

Note: Copying QVector is cheap but copying std::vector is expensive, because Qt containers are implicitly shared (copy-on-write) but STL containers are not.

Also, although std::vector is quite similar to QVector, std::string is woefully inadequate compared to QString.

coffeesmoke

@JKSH Yes. :)

kshegunov

@JKSH said in Reference stability in QVector/QList:

Note: Copying QVector is cheap but copying std::vector is expensive, because Qt containers are implicitly shared (copy-on-write) but STL containers are not.

Which is a rather important point if you're passing them around through signals/slots ...