Le point sur unordered_map

Salut Amis d�veloppeurs
J'ai d�couvert il y a pas longtemps l'existence du conteneur std::unordered_map avec msvc 2010.
D'apr�s ce que j'ai lu ce conteneur est plus efficace que la std::map pour tout ce qui est find, insert, erase.....Mais par contre il faut fournir une fonction de hachage qui tient la route..Aussi il y en a qui sont fournies par d�faut....
Moi je veux faire �a : std::unordered_map<std::pair<int,int>, float>.....
Donc la question est : est-ce que j'ai une fonction de hachage appropri�e pour
les std::pair...ou faut-il la fournir....En gros quel condition doit-remplir un type pour �tre cl� d'une unordered_map....
N.B : Je suis en plein dans un projet donc j'ai pas trop le temps de chercher en profondeur...Merci de me filer un coup de main .

Je me repond moi-meme car j'ai trouv�.....
Pour ceux qui ont le meme probleme sachez que boost fournit dans son header
boost/functional/hash/extensions.hpp des fonctions de hach pour std::pair<> et tous les conteneurs.

Attendez...c'est pas encore fini;)...J'ai un autre petit probl�me
Je veux modifier une cl� dans mon unordered_map par it�rateur mais apparemment c'est prot�g� car quand j'essaie-->erreur de compilation...

Je ne maitrise pas encore ce conteneur mais je sais que avec map il peut y avoir des soucis car c'est ordonn� en permanence...mais l� il n'y a pas d'ordre...

Alors Est-ce que quelqu'un sait comme proc�der pour modifier les valeurs des cl�s tout en gardant la meme position...???
Merci

Le nom est trompeur... Les unordered_map sont aussi ordonn�es, mais pas selon des crit�res que tu definis toi-m�me. Logiquement tu ne peux pas modifier la cl�.

Salut,
ordonn�e ou pas, une map est une association entre une cl� et une valeur. Modifier la cl� revient � supprimer une ancienne association pour en cr�er une nouvelle.
L'id�e sous jascente des map (ordered) est d'utiliser la relation d'ordre strict pour construire un arbre binaire des �l�ments et permettre leur recherche en log(n). L'inconv�nient est que l'insertion ou la suppression d'un �l�ment est couteuse car cela demande de retravailler sur l'arbre.
L'id�e des unordered map est d'utiliser une fonction de hachage pour segmenter l'ensemble des cl�s en diff�rents sous-ensembles plus r�duits (un peu comme les CMap des MFC), l'association dans le sous-ensemble �tant g�r�e plus 'basiquement' (les MFC font une liste cha�n�e si je me souvient bien). Le principe est d'avoir une fonction de hachage qui minimise les collisions, �ad qui minimise le nombre de cl�s qui ont le m�me hash. L'insertion et la suppression peuvent �tre alors plus rapide (comme dans une liste cha�n�e par expl) mais la recherche est un peu moins performante.

Citation:

---

L'insertion et la suppression peuvent �tre alors plus rapide (comme dans une liste cha�n�e par expl) mais la recherche est un peu moins performante.

---

Qu'entends-tu par moins performante ??? car selon ce que j'ai lu les unordered_map sont plus rapides que les map que ce soit pour l'insertion, la suppression mais aussi pour la recherche....

Salut, voici les infos sur les conteneurs de Qt : http://qt.developpez.com/doc/latest/...mic-complexity

A savoir que QHash correspond au std::unordered_map et QMap au std::map. M�me s'il ne s'agit pas exactement de la m�me impl�mentation, les algos sont les m�mes derri�re, donc la complexit� aussi. Pour r�sumer l'unordored_map sera plus rapide en moyenne pour n'importe quelle action (insertion, suppression, recherche), par contre le pire (lorsque la fonction de hachage cr�e beaucoup de collisions) est plus important qu'avec une map (en arbre).

il faut savoir que les unordered_map ont un gros defaut: lorsqu'on depasse une certqine taille (qui double a chaque fois) l'ensemble va etre reallou�, toute les cl�s de hachage vont etre recalcul�es (ca depend de l'implementation bien sur mais la derniere fois que j'avais essay� sur crosof c'etait comme ca) et donc la performance a l'insertion chute

Citation:

---

Envoy� par screetch

il faut savoir que les unordered_map ont un gros defaut: lorsqu'on depasse une certqine taille (qui double a chaque fois) l'ensemble va etre reallou�, toute les cl�s de hachage vont etre recalcul�es (ca depend de l'implementation bien sur mais la derniere fois que j'avais essay� sur crosof c'etait comme ca) et donc la performance a l'insertion chute

---

D'ailleurs j'ai une question � ce propos :
Si l'on connais approximativement le nombre max d'�l�ment que l'on va mettre dans sa hash table, est-ce qu'il n'y a pas moyen de faire l'�quivalent d'un reserve() en jouant avec les fonction max_load_factor() et rehash() ?

la derniere fois que j'ai regard� sur l'implementation microsoft (c'etait il y a 4 ans quand meme) cette methode n'existait pas d'ou la lenteur. On a obtenu un speedup d'environ 90% en remplacant un hash map par un map simplement a cause de ca (le hash map passait son temps a grandir).

Merci � tout le monde pour vos avis.....
Donc apparement vous me conseillez d'utiliser une map � la place....
Juste une derni�re chose : j'ai cru lire sur le site de microsoft que toutes les op�rations seraient en O(1) si l'on connaissait la taille maxi � l'avance..
Dans ce cas on pourrait d�clarer ainsi std::unordered_map MY_MAP(SIZE_MAX);
Est-ce que je pourrais avoir votre confirmation l�-dessus sachant que j'ai un petit doute (SIZE_MAX repr�sente t-elle la taille des �l�ments ou des buckets ??)
Sans oublier que la fonction hash que j'utilise provient de sa majest� boost...;)
Merci

oui dans ce cas ca marche :) size_max repr�sente le nombre d'�l�ments que tu vas ins�rer dans le hash_map (si je comprends bien)

L'id�al est de faire des benchs entre map et unordered_map dans le cas d'utilisation souhait� (ce qui est d'autant plus simple que les interfaces sont quasiment identiques). J'ai eu plusieurs t�moignages indiquant que malgr� une complexit� meilleure en moyenne, en pratique map avait tendance � �tre plus efficace que unordered_map tant que le nombre de donn�es n'�tait pas tr�s grand.

Ok Je fais un bench et je vous tiens au courant....s'il y en a qui veulent en faire aussi... ce sera cool....

Bon Le verdict est tomb�....
J'ai fait 3 benchs :
- INSERT ---> UNORDERED_MAP :1733 us | MAP :909 us
- INSERT + FIND ---> UNORDERED_MAP :2456 us | MAP :1571 us
- INSERT + FIND + ERASE ---> UNORDERED_MAP :4482 us | MAP :2906 us
Info Bench : us = microsecond

Voici le code du 3�me Bench :
Pour la map :

Citation:

---

PerfChrono chrono;
std::map<std::pair<GLint,GLint>, GLfloat> TEMP_MAP;
std::cout<<"Frequence de l'horloge : "<<chrono.GetFreq()<<" Hz."<<std::endl;
GLint ind1 =0;
GLint ind2 =1;
GLfloat val = 2.5f;
chrono.Start();

for(GLint i=0; i<100; i++){
TEMP_MAP.insert(std::make_pair(std::make_pair(++ind1,++ind2),++val));
TEMP_MAP.find(std::make_pair(i+2,i+3));
TEMP_MAP.erase(std::make_pair(i*2,i*3));
}

std::cout<<"Time elapsed = "<<chrono.GetDiffUs()<<std::endl;

---

Et celui de l'unordered_map :

Citation:

---

std::unordered_map<std::pair<GLint,GLint>, GLfloat, boost::hash<std::pair<GLint,GLint> > > TEMP_MAP(100);
std::cout<<"Frequence de l'horloge : "<<chrono.GetFreq()<<" Hz."<<std::endl;
GLint ind1 =0;
GLint ind2 =1;
GLfloat val = 2.5f;
chrono.Start();

for(GLint i=0; i<100; i++){
TEMP_MAP.insert(std::make_pair(std::make_pair(++ind1,++ind2),++val));
TEMP_MAP.find(std::make_pair(i+2,i+3));
TEMP_MAP.erase(std::make_pair(i*2,i*3));
}

std::cout<<"Time elapsed = "<<chrono.GetDiffUs()<<std::endl;

---

Comme vous pouvez le constater la std::map l'emporte haut la main(pr�s du double des perfs)...J'avoue, je suis assez surpris sachant que j'utilise une fonction hash de boost...bizarre non??
Sinon � quoi �a servirait cette structure ??

100 ca n'est pas beaucoup, la complexit� entre a peine en jeu.
Le probl�me c'est que le map a une complexit� en O(log(n)) tandis que le unordered_map a une complexit� en O(1), donc lorsque n est petit les deux sont similaires mais lorsque n grandit la complexit� de map tend vers l'infini (mais t`res tr�s doucement)
je pense que le unordered_map n'est vraiment utile qu'au dela de 50000 objets
meme so a partir de 100, avec une bonne impl�mentation, il devrait deja etre assez performant -_-
il y a aussi peut etre trop de collisions
enfin, si je suis bien, ton erase et ton find ne trouve jamais rien?

Je ne parlais pas d'un bench dans un exemple d�corr�l� de tout, mais d'un bench dans le cadre de ton application, avec des vraies donn�es en entr�e, pour savoir en fonction du nombre, mais aussi du conditionnement de tes donn�es, laquelle de ces deux structures est plus int�ressante.