Discussion :

[Progs]

Bonjour,

J'ai utilisé un conteneur de la stl qui contient des elements d'un type de classe que j'ai défini.
Le truc c'est que j'aimerais qu'il y ait des pointeurs qui pointent sur des elements du conteneur.

Le soucis c'est qu'apparament les adresses changent. En effet, voici une évolution :

0x8088360 (1)

0x8089a90 (1)
0x8089ab0 (2)

0x808ba60 (1)
0x808ba80 (2)
0x808baa0 (3)

Ceci avec un std::vector<A>. J'ai essayé avec un std::deque<A> ça avait l'air un peu mieux au début mais au final l'adressage change tout de même.

Alors j'aimerais savoir si il y avait un conteneur avec des adresses fixes par hasard svp ? Ou alors une methode alternative ?
A la base je faisais un conteneur de pointeurs (std::vector<A*>), mais j'ai cherché à faire un conteneur direct du type pour éviter les new/delete vu d'autant plus que le vecteur fait partit d'une classe elle meme, donc avantageux.

Bref je ne sais pas si je suis clair.

Je vous remercie.

[moldavi]

Salut.

Est-ce que l'utilisation des itérateurs ne suffit pas à résoudre ton problème?

[Progs]

Ben non, moi ce qu'il me faudrait c'est qu'un pointeur à coté qui pointe sur un element de la liste n'ait pas le problème d'un changement de localisation dans la mémoire de celui ci.

[Laurent Gomila]

std::list, std::set et std::map sont je crois les seuls conteneurs qui n'invalident pas les itérateurs au cours du temps. Les autres conteneurs peuvent le faire aussi, si tu n'utilises pas certaines opérations.

Le changement d'adresse que tu constates vient simplement du fait que pour grandir, le vector a besoin de réallouer ses éléments ailleurs en mémoire.

[Luc Hermitte]

En conclusion, avec les autres conteneurs pouvant invalider adresses et itérateurs, il faut stocker des indices.

[Progs]

Ah ok j'avais lu sur le forum que seul std::vector était dans ce cas. Je voulais tester std::list mais comme il n'y avait pas la possibilité de se servir d'un indice.

La solution à laquelle j'ai pensé cette nuit était de se servir d'un std::map et, au lieu de stocker un pointeur, stocker juste la chaine qui permettrait de retrouver le membre du conteneur.

[JolyLoic]

std::list, std::set et std::map sont je crois les seuls conteneurs qui n'invalident pas les itérateurs au cours du temps.

Sauf évidemment les itérateurs d'éléments qu'on a supprimé.

Juste une question à l'OP : Pour quoi faire ?

Souvent, quand on veut avoir des pointeurs sur A, on veut avoir un conteneur<A*> et non pas un conteneur<A>. N'est-ce pas ton cas ?

[Progs]

Non. En gros j'ai un type player, un type channel et un type client. Je veux un conteneur de players dans le channel et tout simplement un pointeur vers le player (quand il existe) dans la classe client.

Et pour éviter de nombreux new/delete j'ai pensé qu'utiliser un conteneur<Player> plutot que conteneur<Player*> serait plus simple, car:
- le simple retrait supprime l'element sans delete.
- la suppression de l'instance de channel supprime tous les elements player du conteneur.
- ça evite les try/catch.

[Laurent Gomila]

Sauf que comme ça tu t'exposes à de nombreuses copies, et Player n'est typiquement jamais une classe copiable.

[Progs]

Hm en effet, mais c'est pour ça que je pensais utiliser que des pointeurs pour manipuler un Player.

Bon vous me conseillez de revenir à la technique des conteneur::<Player*> ?

[Laurent Gomila]

Si Player possède une sémantique de référence, c'est la seule bonne solution (tu peux par contre ajouter un pointeur intelligent histoire de sécuriser le tout).

[Progs]

Comment ça une "sémantique de référence" ?

[Laurent Gomila]

Par opposition à une sémantique de valeur.

Une classe possédant une sémantique de valeur sera copiable / affectable, et deux de ses instances seront égales si elles ont la même "valeur" (ex : les chaines, les entiers, ...), peu importe qu'il s'agisse de deux instances différentes.

Une classe possédant une sémantique de référence ne sera pas copiable, et deux de ses instances ne seront égales que s'il s'agit du même objet en mémoire (ex : les personnages, ou encore généralement tout ce qui provient d'une hiérarchie d'héritage publique) ; donc même si tu as deux objets possédant le même "état interne", ils seront toujours différents.

Pour retenir c'est facile : les classes posédant une sémantique de valeur se manipuleront par valeur / copie, alors que les classes possédant une sémantique de référence seront manipulées par référence / pointeur.

C'est vraiment pas évident à expliquer comme ça, et d'ailleurs si Luc, Loïc ou Jean-Marc passe par là je suis sûr qu'il se fera un plaisir de le faire mieux que moi.

[Progs]

En somme c'est la meme chose que si on compare deux pointeurs sur deux objets différents mais égaux membres à membres (false) et si on compare deux objets différents egaux membres à membres (true) ?

En tous cas je pense que je vais devoir me résigner à refaire un vecteur de pointeurs. Ce qui m'énerve c'est que j'avais utilisé cette solution mais j'avais peur de fuites de mémoires etc donc je me suis dis que ça serait plus simple. Mais finalement c'est le bordel.
Donc je vais devoir défaire *tout* ce que j'ai fais.

[Fiquet]

Une classe possédant une sémantique de valeur sera copiable [...]

Une classe possédant une sémantique de valeur ne sera pas copiable [...]

il faudra lire "sémantique de référence pour la deuxième

[Progs]

oui j'avais bien compris :)

[Luc Hermitte]

C'est ça. Dans la sémantique de valeur, le contenu définit l'identité. On dispose de copiabilité et de comparabilité.
Dans la sémantique de référence, l'entité définit l'identité. (En ignorant le passif cognitif et autres contextes, deux vrais jumaux ou deux clones sont bien deux entités différentes malgrè le même "contenu")


Sinon, tu as des pointeurs intelligents pour éviter les fuites de mémoire. Ils permettent d'offrir le RAII aux objets manipulés dynamiquement.

[Progs]

Est-ce qu'utiliser des pointeurs intelligents est une véritable solution ou n'est-ce pas plutot une facilité qui permet de faire encore plus de conneries sans s'en rendre compte ?

[Luc Hermitte]

C'est une solution qui permet d'avoir un code correct (en particulier résistant aux exceptions) et surtout maintenable (non truffé de try-catch toutes les 10 lignes).

[Progs]

Oui alors ça c'est quelque chose d'interressant. En effet c'est chiant de devoir mettre pleins de try/catch, et en particulier l'indentation, ça parrait négligeable mais pour de grosses fonctions ça devient très vite lourd.

Je vais me renseigner plus en profondeur sur les pointeurs intelligents (FAQ) et probablement utilsier ça.

La question est: est-il possible/facile d'utiliser un conteneur de pointeurs intelligents ?:).