Hi. For the new code variant you might want to follow the idea hehind the change of the QSet API, and avoids the intermediate QList<QString> creation (here and in similar changes):

#if QT_VERSION < QT_VERSION_CHECK(5, 14, 0)
return QSet<QString>::fromList( mRanges.uniqueKeys() );
#else
  return QSet<QString>( mRanges.keyBegin(), mRanges.keyEnd() );
#endif

More performant (no mallocs for the intermediate list), and less code to write & read :) The iterators over the keys are const methods, so no detaching is done.

In R125:af7c68f76b3bc0835660cf661d30b60a42251218#3891775, @kossebau wrote:

Hi. For the new code variant you might want to follow the idea hehind the change of the QSet API, and avoids the intermediate QList<QString> creation (here and in similar changes):

#if QT_VERSION < QT_VERSION_CHECK(5, 14, 0)
return QSet<QString>::fromList( mRanges.uniqueKeys() );
#else
  return QSet<QString>( mRanges.keyBegin(), mRanges.keyEnd() );
#endif

More performant (no mallocs for the intermediate list), and less code to write & read :) The iterators over the keys are const methods, so no detaching is done.

Thank you, I didn't know.
Do you want me to do the changes as it is better?

Yes, IMHO would be good to do, to spread usage/knowledge about the better code.

In R125:af7c68f76b3bc0835660cf661d30b60a42251218#3891783, @kossebau wrote:

Yes, IMHO would be good to do, to spread usage/knowledge about the better code.

Thanks, it's pushed in 0a26fa2ca84c6c0bf84a8531b739e9636888e555

Thank you for your work :)