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

[Milian Wolff]

On Saturday, July 11, 2015 04:43:49 PM Konrad Rosenbaum wrote:
> On Friday 10 July 2015 17:01:04 Smith Martin wrote:
> > And apparently QVector has the same API as QList now, so why don't we
> > deprecate QList. Let it always create a QVector.
> 
> Do you mean deprecate for use inside Qt? Maybe in Qt 6 or 7.
> 
> In general? For user code as well? HELL NO! (sorry for the shouting...)
> 
> Thiago listed a few exceptions under which the use of lists is legitimate.
> These situations exist - more frequently than some of you seem to believe.
> At least in code that was not written under ideal circumstances (which in my
> sad little corner of industry is about 99.5% of all code).
> 
> Believe it or not - I've got plenty of code in which I frequently and
> dynamically change the size of lists of complex objects. Doing this with
> QVector would create its own kind of re-allocation hell. And no, for most of
> these instances it's impossible to predict how large the list will be
> before it is complete - it often depends on data that first needs to be
> parsed, analysed, requested, or otherwise pulled piecewise out of some
> remote process' tight grasp.
> 
> If Qt deprecated QList I would have to convert a lot of legacy code to
> std::list; neither QVector (allocation hell) nor QLinkedList (slow retrieval
> with large data sets) are serious alternatives.

Did you actually profile this? I don't see how a QVector could lead to 
"allocation hell", where QList would not be much worse. Can you explain your 
use case better please? Esp. how large are your items?

What you describe up there seems to be very common, I often do the same, and 
always QVector is the better choice. Thanks to the growth strategies, repeated 
push_back is not that bad, esp. compared to QList which has the same number of 
allocations for its array, and then on top often per-item allocations. So I 
really don't understand how it can be better...

Bye
-- 
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5903 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150711/19dc5fea/attachment.bin>