Would it simplify things to use a QSet instead?

KNewStuff does not use d pointers so changing QHash<QString, EntryInternal::List> to QHash<QString, QSet<EntryInternal>> will result in binary incomparability, no?

Technically no, since it doesn't change the size of the class itself (and requestCache is private and isn't used in any inline method).

The benefit of QSet over a linear search only starts after a large enough amount of elements in the set though. I have no idea about typical sizes here.

In D9318#179477, @dfaure wrote:

Technically no, since it doesn't change the size of the class itself (and requestCache is private and isn't used in any inline method).

You are right, size will not change.

In D9318#179477, @dfaure wrote:

The benefit of QSet over a linear search only starts after a large enough amount of elements in the set though. I have no idea about typical sizes here.

It can be really huge depend of requests intensity.

Any objections?

Well, if this QSet can be huge, then these conversions from QList and to QList are going to take a lot of CPU.
Are you sure it wouldn't be much faster to do a linear search at append time, in exchange for saving all those temporary-containers conversions?
This code looks VERY slow to me, due to the large amount of temporary memory allocations, and linear container conversions.

IMHO the method that returns a List forces us to keep using a List as the data structure.