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

[Kuba Ober]

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>
wrote:

>
>
>
> 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>