Reference stability in QVector/QList
-
[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 thatint* p = &data[0];
stays pointing to that the data which was stored there (I realize it may no longer be the0
th element over time if inserts, but it will still be in the list), unlike for aQVector
whose data may get moved? -
@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
-
@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.
-
@Christian-Ehrlicher
So if you stored a fair-sizedstruct
(notstruct *
!) as your elements in aQList
, as you appended new elements you would indeed be liable to all the existing elements getting moved in memory? -
@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.
-
@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. -
@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)
-
@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 wheresizeof(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 theQVector
/QList
, then you're explicit and reordering of the pointers doesn't change the object's addresses themselves. -
@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. -
@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. -
@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.
-
@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. -
@coffeesmoke I'm not a fan of snake_case, so I try to stay away from the standard, if I can 😉
-
@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.
-
@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. :)
-
@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 copyingstd::vector
is expensive, because Qt containers are implicitly shared (copy-on-write) but STL containers are not.Also, although
std::vector
is quite similar toQVector
,std::string
is woefully inadequate compared toQString
. -
@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 ...