> Sent: Thursday, April 23, 2020 at 12:05 PM > From: "Giuseppe D'Angelo via Development" <development@qt-project.org> > To: development@qt-project.org > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 > > On 4/23/20 5:04 PM, Julius Bullinger wrote: > > Another suggestion: Get rid if the aliases; use the fully-qualified > > types instead. > > > > I'm always irritated if I open the documentation of QVariantList from > > within Qt Creator, and land on the QVariant docu instead. I'm interested > > in the features of the container, not the contained type. > > This is a documentation bug or a Creator bug. You're supposed to land on > this anchor: https://doc.qt.io/qt-5/qvariant.html#QVariantList-typedef > > > And I have to remember if QStringList is the same as as QList<QString>, > > or if it's actually a different container with a different API. > > 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. 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. 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); _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development