insertion dans une map

Bonjour, j'ai une std::map<int,int> m;

Je fais quelque chose du genre

Code:

---

1 2 3

for(int i = 0 ; i < N ; i++) m.insert(std::make_pair(i,2 * i));

---

(l'exemple est b�te, mais l� n'est pas ma question). En gros, je fais toujours une insertion dans ma map au dernier �l�ment. J'ai vu que je pouvais indiquer via un iterator, un "indice" � partir du quel ins�rer mon nouvel objet. L'exemple pr�c�dent deviendrait alors

Code:

---

1 2 3

for(int i = 0 ; i < N ; i++) m.insert(m.end(),std::make_pair(i,2 * i));

---

L'id�e �tant de gagner du temps de calcul.

Maintenant, voici un exemple (avec ma question dedans) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

#include <map> #include <iostream> using namespace std;   void printMap(const map<int,int> & m) { //for(size_t i = 0 ; i < m.size() ; i++) map<int,int>::const_iterator it; for(it = m.begin() ; it != m.end() ; it++) cout << it->first << " : " << it->second << endl; cout << endl; }   int main() { map<int,int> m;   m.insert(make_pair(0,0)); m.insert(make_pair(3,3)); m.insert(make_pair(2,2)); m.insert(m.end(),make_pair(4,4)); m.insert(m.begin(),make_pair(5,5)); m.insert(m.end(),make_pair(1,1)); // pourquoi cet élément est-il inséré ? m.insert(make_pair(2,0));   printMap(m);   return 0; }

---

J'avoue ne pas comprendre pourquoi l'�l�ment (1,1) est ins�r� car je lui ai dis d'ins�rer � partir du dernier �l�ment...

Merci d'avance de vos r�ponses.

Hello,

Sp�cifier un iterateur de position ne veut pas dire que ton �l�ment va �tre ins�r� exactement � cette position. La map �tant un conteneur tri�, l'�l�ment � ins�rer se retrouvera toujours � sa bonne position, d�pendant uniquement de l'op�rateur de comparaison fourni en param�tre template de la map (si je dis pas de b�tises). Le param�tre de position veut dire, en gros, que la recherche de la vrai position d'insertion commencera � la position donn�e (ce qui peut faire gagner pas mal de temps).

Salut,

Tu sembles oublier que la std::map agit comme un arbre binaire �quilibr�, afin d'assurer sa capacit� � assurer une recherche en O(log n).

Chaque insertion sera donc obligatoirement suivie par un r��quilibrage de l'arbre, et tu ne gagnes absolument rien � demander � ce que l'insertion se fasse � la fin de la collection.

Au contraire, j'aurais tendance � estimer que tu force le d�s�quilibre de l'arbre, et donc que tu perds plus de temps que tu ne pourrais en gagner en laissant la std::map s�lectionner d'elle-m�me le meilleur endroit pour ins�rer le nouvel �l�ment ;)

Citation:

---

Envoy� par vikki

Hello,

Sp�cifier un iterateur de position ne veut pas dire que ton �l�ment va �tre ins�r� exactement � cette position. La map �tant un conteneur tri�, l'�l�ment � ins�rer se retrouvera toujours � sa bonne position, d�pendant uniquement de l'op�rateur de comparaison fourni en param�tre template de la map (si je dis pas de b�tises).

---

C'est effectivement en fonction de l'op�rateur de comparaison "plus petit que"

Citation:

---

Le param�tre de position veut dire, en gros, que la recherche de la vrai position d'insertion commencera � la position donn�e (ce qui peut faire gagner pas mal de temps).

---

Cela peut faire gagner du temps si tu a d�j� pu d�terminer un sous ensemble de ta collection dans lequel tu es sur que ton nouvel �l�ment prendra place.

Or, la fin de la std::map n'est que rarement un tel sous ensemble :aie:

On est d'accord, �a n'arrive pas souvent (en fait jamais pour moi). Par contre il suffit que la position sp�cifi�e soit inf�rieure � l'�l�ment � ins�rer (au sens du std::less ou autre foncteur) pour gagner (un peu, ca d�pend du nombre d'�l�ments dans la map pr�c�dant la positions sp�cifi�e) de temps. Si l'�l�ment situ� directement apr�s cette position est sup�rieur � l'insertion, la map effectuera sa tambouille interne classique pour d�terminer la position ad�quate (donc en partant du plus petit �l�ment je crois, pas s�r). Tout �a pour dire que �a sert pas � grand chose :aie:

En fait, le tri se fait par �quilibrage de l'arbre sous-jasent, avec tout ce que cela implique de permutations d'�l�ment pour arriver � �quilibrer l'arbre "global".

Je suspecte en fait que la possibilit� de pr�ciser une position d'insertion est essentiellement due au souhait de fournir une interface similaire pour l'ensemble des collections supportant l'insertion, car tu ne peux m�me pas avoir la certitude que si tu fournis une position dont la comparaison "less than" est v�rifi�e rendra l'�quilibrage plus rapide :P