[Development] How bad QList really is

[André Pönitz]

On Wed, Apr 29, 2020 at 01:41:46AM +0200, Giuseppe D'Angelo via Development wrote:
> Il 28/04/20 21:45, Matthew Woehlke ha scritto:
> > > * QList gets adapted so that its internal array allocates 3 *
> > > sizeof(void*) per element, so that e.g. Q6StringList won't require a
> > > per-item allocation. This would then also avoid allocations for other
> > > datatypes, e.g. QStringView, QImage, maybe QVariant and QColor; but
> > > of course waste a ton of space for the ones which remain small (most
> > > of Qt implicitly shared datatypes).
> >
> > Uh... can't it allocate sizeof(T) if T meets some criteria? IOW, I
> > don't see the second case penalizing smaller types unless the
> > implementation is poorly done.
> 
> This way of working is the *key* of QList design.

It happens to be implemented that way.

Why this was done that way I don't *know*, but given that it is optimal
in 98.5% in my cases, I'd guess that it was simply considered "good enough".
Which it actually is.

It is surely not mandatory to have to achieve features like cheap erase at
the beginning etc for that.

*If* the workload changes in Qt 6 due to the increased QString size, there
could be a specialization for things with, say, 3 x sizeof(void *) for
objects of this size.

And only for those. The 1 x sizeof(void *) for normal cases can be kept.

This "we will have to waste a lot of space" argument is simply wrong.

> QList is alwys a vector of void* (so it's nice for Qt pimpled types).
> This allows to type erase the entire management of the vector (it's
> always a vector of void*), reducing the amount of template code that
> needs to be instantiated.

It is interesting to see that the "code size" argument shows up as super
important elsewhere, but doesn't play a role when it gets into the way of
killing QList.

Andre'