[Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

Kuba Ober kuba at mareimbrium.org
Fri Aug 7 19:38:56 CEST 2015

That's an interesting observation. Would it be easy to add an api to QList
and QVector that would somehow keep track of the empty spots and use them
if available? In a `QList`, it would require only an extra pointer to the
first "empty" member slot, the slots would act as a singly-linked list.
Same for `QVector`. I wonder if such an api would find wider use. I've just
looked through ~150k LOC of code that is built on top of Qt, and >60% of
the uses of `QList` and small vectors don't in fact care about the order

On Tue, Jul 21, 2015 at 5:55 AM, Bubke Marco <Marco.Bubke at theqtcompany.com>

> From: development-bounces+marco.bubke=theqtcompany.com at qt-project.org
> <development-bounces+marco.bubke=theqtcompany.com at qt-project.org> on
> behalf of Kevin Kofler <kevin.kofler at chello.at>
> > If you have large objects, and insert or remove items within the list,
> > QVector will have to move (or even copy&delete, if they're not movable)
> > large amounts of data. Unless you use a QVector<T*>, but that loses the
> > value semantics in several places. And a QLinkedList is not an option if
> you
> > also need O(1) (or anything faster than O(n), even) item retrieval.
> Pointer
> > arrays have their advantages.
> It depends if you care about the order of the container. If you don't and
> my
> experience you don't care in many cases you can simply use std::remove_if
> + erase
> and being very efficient.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150807/294ca50b/attachment.html>

More information about the Development mailing list