Solved Reference stability in QVector/QList
-
@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 Yes. :)
-
@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 ...