Is it possible to have duplicate in QSet/Hash ?
-
wrote 17 days ago last edited by aha_1980 6 Apr 2025, 15:13
Hello,
I just wanted to ask a simple question to confirm what I'm trying to understand.
From what I have understood so far, Qset/Hash documentation doesn't say anything about the potentiality of a duplicate, but the way they are made, if a data is inserted in a Qset on which the data already exists, it will not create a second entry on the QSet ? Otherwise, with the arbitrary order of data storage, it would be impossible to differentiate them.
So my question based on this understanding is : If I don't want duplicates (compared to the case of a QList), is it always true that if I have two exact entries I have no duplicates ?
Exemple :
QSet<QString> set; set.insert("one"); set.insert("three"); set.insert("one");
In this case, inspried by the one of the documentation, I will only have
"one"
and"three"
stored ?And will be the case for every type of data, even in the case of a
Qset<QListe<QString>>
? (the one I actually want to use)I did not found where this propriety even if logic is stated, if it exist at all.
-
Hello,
I just wanted to ask a simple question to confirm what I'm trying to understand.
From what I have understood so far, Qset/Hash documentation doesn't say anything about the potentiality of a duplicate, but the way they are made, if a data is inserted in a Qset on which the data already exists, it will not create a second entry on the QSet ? Otherwise, with the arbitrary order of data storage, it would be impossible to differentiate them.
So my question based on this understanding is : If I don't want duplicates (compared to the case of a QList), is it always true that if I have two exact entries I have no duplicates ?
Exemple :
QSet<QString> set; set.insert("one"); set.insert("three"); set.insert("one");
In this case, inspried by the one of the documentation, I will only have
"one"
and"three"
stored ?And will be the case for every type of data, even in the case of a
Qset<QListe<QString>>
? (the one I actually want to use)I did not found where this propriety even if logic is stated, if it exist at all.
wrote 17 days ago last edited by Pl45m4 6 Apr 2025, 13:13@AntGP said in Is it possible to have duplicate in QSet/Harsh ?:
Qset/Harsh documentation doesn't say anything about the potentiality of a duplicate, but the way they are made, if a data is inserted in a Qset on which the data already exists, it will not create a second entry on the QSet ?
At least for
QHash
it does...QHash is unordered, so an iterator's sequence cannot be assumed to be predictable. If ordering by key is required, use a QMap.
Normally, a QHash allows only one value per key. If you call insert() with a key that already exists in the QHash, the previous value is erased. For example:
hash.insert("plenty", 100); hash.insert("plenty", 2000); // hash.value("plenty") == 2000
(https://doc.qt.io/qt-6/qhash.html)
That also includes assigning the same value again... which means the
QHash
pair is updated (to the same value but that does not matter here)... So no multiple values for the same hashed key.For this there is
QMultiHash
, which allows multiple values per key.Edit:
Because
QSet
has an internalQHash
table but no key, I think the same applies. -
wrote 17 days ago last edited by
Thx ! it answered my question perfectly !
-
-
Hello,
I just wanted to ask a simple question to confirm what I'm trying to understand.
From what I have understood so far, Qset/Hash documentation doesn't say anything about the potentiality of a duplicate, but the way they are made, if a data is inserted in a Qset on which the data already exists, it will not create a second entry on the QSet ? Otherwise, with the arbitrary order of data storage, it would be impossible to differentiate them.
So my question based on this understanding is : If I don't want duplicates (compared to the case of a QList), is it always true that if I have two exact entries I have no duplicates ?
Exemple :
QSet<QString> set; set.insert("one"); set.insert("three"); set.insert("one");
In this case, inspried by the one of the documentation, I will only have
"one"
and"three"
stored ?And will be the case for every type of data, even in the case of a
Qset<QListe<QString>>
? (the one I actually want to use)I did not found where this propriety even if logic is stated, if it exist at all.
wrote 17 days ago last edited by@AntGP said in Is it possible to have duplicate in QSet/Harsh ?:
Thx ! it answered my question perfectly !
Great!
@AntGP said in Is it possible to have duplicate in QSet/Harsh ?:
even in the case of a
Qset<QListe<QString>>
? (the one I actually want to use)For convenience use
QSet<QStringList>
instead, which is exactly aQList
ofQString
s plus some extra features -
wrote 17 days ago last edited by AntGP 6 Apr 2025, 13:38
It would have been a good suggestion , but.... i'm not the one who made the
Qlist<Qstring>
... i'm trying to look at something 12 years old, made over 10 years by at least 3 differents persons whit no doc -
It would have been a good suggestion , but.... i'm not the one who made the
Qlist<Qstring>
... i'm trying to look at something 12 years old, made over 10 years by at least 3 differents persons whit no docwrote 17 days ago last edited by Pl45m4 6 Apr 2025, 13:49@AntGP said in Is it possible to have duplicate in QSet/Harsh ?:
i'm not the one who made the Qlist<Qstring>
That should not matter?!
But you are trying to put thatQList<QString>
construct in a container of your choice (QHash
/QMap
/QSet
) right?
So you can still make itQSet<QStringList>
and add the old data to it, in factQStringList
IS aQList<QString>
, with its own API on top.Of course you don't have to... but sometimes things like
QStringList() << "Foo" << "Bar" << "42" << "Mooh";
as well as joins and filters, come quite handy :)
-
wrote 17 days ago last edited by AntGP 6 Apr 2025, 14:04
To be honnest, looking more deeply in Qhash than i'v done before, it appered that it was the perfect tool for a bit later.
Once my thing is working and I have fixed my own mess, I'll take a look at improving what mess have been made before me.
1/7