std::list, std::vector et allocation m�moire

Bonjour,

Une question que je me pose sur l'allocation de m�moire dans les listes et les vecteurs :

Est-il possible de stocker dans un pointeur l'adresse d'un objet ins�r� dans une liste ou dans un vecteur et d'�tre s�r que ce pointeur pointe toujours sur l'objet ?

En gros, faire :

Code:

---

1 2 3 4 5

std::list conteneur; ou std::vector conteneur; cObject objet; cObject *pObjet = &objet;   conteneur.push_back(objet);

---

Pour les listes, il s'agit de listes chain�es, donc � priori, pas de soucis...

Mais pour les vecteurs, que se passe-t-il en cas de r�allocation (pour cause de d�passement, par exemple) ?

Est-ce qu'au moment de la r�allocation, l'objet lui-m�me est d�plac� ?
Ou est-ce que seulement la zone r�serv�e pour les it�rateurs est r�allou�e et seulement les it�rateurs sont d�plac�s ?

Merci !

Si tu prends l'adresse avant insertion, tu es coul� � tous les coups car c'est une copie qui est stock�e. Si tu la prends apr�s, elle est valide tant que tu ne fais pas d'op�ration invalidante sur ton conteneur :
- Suppression et ajout de n'importe quel �l�ment dans un vector, un deque ou un string
- Suppression de l'�l�ment en question dans tout autre conteneur (list, set, map)

Pour les vecteurs il est certain que �a ne fonctionnera pas.
Sinon, il y a un truc formidable pour ne pas avoir � se poser la question: boost::ptr_container. Ce sont des variantes point�es des containers de la stl.
En dehors de �a, stocker des it�rateurs serait peut-�tre pr�f�rable, mais d'autres sur ce forum t'en diront plus sur le sujet (je ne suis pas certain de la fa�on dont �voluent les it�rateurs si leur conteneur est modifi�).

Laurent Gomila :

Citation:

---

car c'est une copie qui est stock�e

---

Tu veux dire que l'ensemble de mon objet est recopi� pour l'insertion ?
L'objet existe donc 2 fois en m�moire ?

Citation:

---

Suppression et ajout de n'importe quel �l�ment dans un vector, un deque ou un string

---

Tu veux dire que si j'insere un autre �l�ment apres celui-ci, son adresse a chang�e ?

Citation:

---

Suppression de l'�l�ment en question dans tout autre conteneur

---

Je suppose que c'est parceque le destructeur de l'�l�ment est appel� lors de sa suppression d'un autre conteneur... Mais si l'objet est recopi� lors de son insertion, pourquoi �a pose soucis ?

Citation:

---

En dehors de �a, stocker des it�rateurs serait peut-�tre pr�f�rable

---

Pointeur ou it�rateur c'est pareil. Par contre pour un vector on peut stocker des indices, �a peut aider dans certains cas.

Citation:

---

Tu veux dire que l'ensemble de mon objet est recopi� pour l'insertion ?
L'objet existe donc 2 fois en m�moire ?

---

Oui. Enfin comme le premier est d�clar� sur la pile il sera d�truit pas longtemps apr�s.

Citation:

---

Tu veux dire que si j'insere un autre �l�ment apres celui-ci, son adresse a chang�e ?

---

Potentiellement. S'il n'y a pas assez de place, il y aura r�allocation de m�moire et donc d�placement des �l�ments en m�moire.

Citation:

---

Je suppose que c'est parceque le destructeur de l'�l�ment est appel� lors de sa suppression d'un autre conteneur...

---

Ben c'est surtout parce que l'�l�ment n'existe plus. Donc tout pointeur qui pointerait dessus deviendrait invalide.

Citation:

---

Mais si l'objet est recopi� lors de son insertion, pourquoi �a pose soucis ?

---

Parce que c'est sur la copie que tu pointes. L'original ayant �t� d�truit depuis longtemps.

Ok, merci pour toutes ces precisions.

Je vais un peu preciser le contexte :

Je cr�e des objets, suite � des actions de l'utilisateur. Donc de facon dynamique.

La liste de certains de ces objets doit �tre parcourue tr�s tr�s fr�quemment pour en lire le contenu.

Le parcours de cette liste est � peu de chose pr�s, le coeur de mon programme. Je souhaite donc l'optimiser au maximum.

Dans un premier temps, j'ai fait �a :

- cr�ation de chaque objet avec un new()
- insertion dans une std::list
- parcourt de la liste

Ensuite, �a :
- cr�ation de chaque objet avec un new()
- insertion dans un std::vector
- parcourt du vecteur

Ici, j'ai gagn� un d�r�fencement � chaque parcourt de la liste, au prix d'une r�allocation de temps en temps (pas tr�s grave)

Maintenant, j'essaie de faire en sorte que chaque objet cr�� puis ins�r� soit dans la m�me zone m�moire que les autres, afin d'�viter de devoir recharger le cache m�moire � chaque fois que l'on passe � l'objet suivant.

Je pensais trouver une astuce en les allouant sur la pile afin qu'ils soient proches les uns des autres... visiblement c'est rap� !

Auriez-vous des suggestions ?

Salut,

Si ton vecteur (ou ta liste ou ... d'une mani�re g�n�rale, ton conteneur) est pr�vu pour contenir des pointeurs, rien ne t'empeche d'�crire un code du genre de

Code:

---

1 2 3 4

monvecteur.push_back(new MonObjet(...)); mamap.insert(std::make_pair(key,new Monobjet(...)); //etc

---

Les ... dans les parentheses repr�sentant, bien �vididemment, les arguments � passer au constructeurs ;)

Tu te pose bien beaucoup de questions, et certains de tes raisonnements sont bizarres. Pour choisir ton conteneur, voici ce que tu dois te dire:
- si tu fais des ajouts/suppressions fr�quents en mileu de liste, prends une list
- si tu fais des parcours al�atoires, prends un vector
- les deux? normalement un deque doit te fournir un compromis
Pense aussi � jouer avec la capacit� des vector et des deque.
Et �a ne sert � rien d'instancier par pointeur si c'est pour copier ton objet dans un conteneur juste apr�s, de m�me que c'est un peu l'inverse que de vouloir optimiser le cache m�moire (puisque tes objets peuvent �tre instanci�s n'importe o� dans la m�moire). Soit dit en passant, pense plutot � minimiser la complexit� de tes algos plutot que d'optimiser le cache m�moire, en g�n�ral �a paie plus :mouarf:

Pour preciser :

- les ajouts/suppressions sont tr�s rares par rapport au nombre de lectures

- je cr�e les objets avec un new() mais je stocke leur reference, pas l'objet lui-m�me, sinon rien ne marcherait

- je ne fais pas de parcourt al�atoire, mais s�quentiel. Eventuellement en commencant au milieu.

- la capacit� des vecteurs est pr�vue pour "a priori" ne pas �tre d�pass�e, sinon tant pis (tres peu d'insertions, donc tres peu de realloc)

- les algos sont d�j� minim�s au maximum (!!!) comme dernier levier d'optimisation, il me reste le parcourt de la liste....

D'apr�s ce que j'ai compris, tu fais un truc du style

Code:

---

1 2 3

std::vector<Object> v; Object* o = new Object; v.push_back(*o);

---

?
C'est-�-dire n'importe quoi ?

meuh non !

Quand meme pas !

Juste :

Code:

---

1 2 3

std::vector<Object> v; Object* o = new Object; v.push_back(o);

---

J'vais quand m�me pas m'amuser a stocker, dans un vecteur, un pointeur sur un pointeur sur un objet.

Surtout si c'est dans le but d'economiser des d�r�ferencements !!!

En m�me temps, on ne sait toujours pas ce que tu fais vu que le code que tu donnes n'est pas correct et n'est donc vraissemblablement pas celui que tu utilises.

Citation:

---

J'vais quand m�me pas m'amuser a stocker, dans un vecteur, un pointeur sur un pointeur sur un objet.

---

Dans le code de loufoque ce n'est pas un pointeur sur un pointeur sur un objet, mais une copie d'un objet allou� sur le tas.

Je suis pas chez moi, j'ai pas tout mon code sous la main, mais j'ai au moins �a :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

// Je declare un vecteur : std::vector<cObjet*> m_vecteurObjet;   // J'y insere des objets (plusieurs) : pObjet = new cObjet(...); m_vecteurObjet.push_back(pObjet);   // Mon traitement principal consiste à : std::vector<cObjet*>::iterator It;   for(It=m_vecteurObjet.begin();It!=m_vecteurObjet.end();It++) { (*It)->traitement(...); }

---

Maintenant : sachant que ma fonction traitement est extrement simple :
- addition d'un membre de l'objet avec un parametre de la fonction
- comparaison du resultat
- stockage du resultat (ou non) dans u autre membre de l'objet

Je souhaiterais rendre le parcourt de la boucle le plus rapide possible :

1/ eviter des d�r�ferencement ?

2/ faire en sorte que tous les objets soient stock�s dans la m�me zone m�moire pour �tre tous charg�s en cache ? (les objets font entre 32 et 64 octets, il y a en une centaine environ)

3/ d'autres pistes ?


D�sol� si je ne suis pas tr�s clair.

Pourquoi tu stockes des pointeurs et pas des objets directement ?

Plusieurs raisons � cela :

- ailleurs dans le code, j'ai besoin d'acceder � certains objets du vecteur. Mais cela pourrait se faire via un indice ou un it�rateur

surtout :

- je ne veux pas que les objets soient d�truits lorsqu'ils sont retir� du vecteur : j'en ai besoin ailleurs

Dans ce cas si ce n'est pas le vecteur qui g�re la dur�e de vie des �l�ments, il faudra bien n'en stocker que des pointeurs.

C'est ce que je pensais.

D'o� l'id�e de cr�er les objets dans la m�me zone m�moire afin d'�viter les erreurs de cache.

Je ne vois pas trop d'autres leviers pour optimiser...

Mais je ne sais pas trop comment faire, ni m�me si �a a un impact significatif, �tant donn� le d�referencement qui precede le chargement de l'objet.

Pourquoi je me prend la tete sur ce bout de code vous demandez-vous peut-etre ?

Parcque c'est un bout de code qui doit tourner � fond les manettes !

Oui, mais :

Citation:

---

Dans ce cas si ce n'est pas le vecteur qui g�re la dur�e de vie des �l�ments, il faudra bien n'en stocker que des pointeurs.

---

Avec seulement une centaine d'objets, on peut pas dire que �a soit vraiment indispensable de "tourner � fond les manettes". Et puis si on commence � compter les d�r�f�rencements, pourquoi pas les appels de fonctions tant qu'on y est?
Sinon, je capte de moins en moins tes explications. Tu nous dit que tes objets sont dans un conteneur mais que ce n'est pas lui qui g�re leurs cycles de vie... :roll: Ce n'est donc qu'une sorte d'index non? Dans ce cas pourquoi t'acharner uniquement la dessus, tes objets devront bien �tre g�r�s par autre chose qui sera probablement un... conteneur. Faudrait pas plutot se pencher la dessus?