[Development] [SPAM] How bad QList really is

Matthew Woehlke mwoehlke.floss at gmail.com
Wed Apr 29 15:41:02 CEST 2020


On 28/04/2020 19.41, 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. QList is always 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.
Okay, I'm going to *assume* that what you're trying to say, poorly, is 
that QList<T> for relocatable T, sizeof(T) ≤ sizeof(void*), is 
implemented in terms of casting the bits of T into an intptr_t, which is 
further mangled into a void*.

Just because that's how it's implemented *now* doesn't preclude a new, 
ABI-breaking version from being implemented as void*[N] for N less than 
some small value. It would increase the code overhead *somewhat*, but 
not unmanageably so (all allowable instances could still be explicitly 
instantiated), and that is probably worth it for the difference in space 
efficiency.

-- 
Matthew


More information about the Development mailing list