Pointeurs sur membres d'un conteneur

Version imprimable

09/02/2006, 21h06
Progs

Pointeurs sur membres d'un conteneur

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.
09/02/2006, 21h17
moldavi

Salut.

Est-ce que l'utilisation des itérateurs ne suffit pas à résoudre ton problème?
09/02/2006, 21h20
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.
10/02/2006, 00h20
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.
10/02/2006, 01h58
Luc Hermitte

En conclusion, avec les autres conteneurs pouvant invalider adresses et itérateurs, il faut stocker des indices.
10/02/2006, 09h24
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.
10/02/2006, 09h36
JolyLoic

Citation:

Envoyé par Loulou24

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 ?
10/02/2006, 09h44
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.
10/02/2006, 09h55
Laurent Gomila

Sauf que comme ça tu t'exposes à de nombreuses copies, et Player n'est typiquement jamais une classe copiable.
10/02/2006, 09h58
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*> ?
10/02/2006, 15h22
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).
10/02/2006, 18h47
Progs

Comment ça une "sémantique de référence" ?
11/02/2006, 12h38
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.
11/02/2006, 13h10
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.
11/02/2006, 13h11
Fiquet

Citation:

Envoyé par Loulou24

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

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

:D il faudra lire "sémantique de référence pour la deuxième ;)
11/02/2006, 13h13
Progs

oui j'avais bien compris :)
11/02/2006, 16h07
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.
11/02/2006, 18h01
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 ?
11/02/2006, 18h09
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).
11/02/2006, 18h28
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 ?:).
11/02/2006, 18h48
Luc Hermitte

Même pour des petites fonctions qui ne font pas grand chose, il est vite pénible d'intercepter toutes les exceptions pour devoir les traduire -- genre si il faut des couches de traductions entre exceptions corba et exceptions du projet.

Et oui, c'est facile à faire. Cf. le classique std::vector<boost::shared_ptr<MonType> >. (d'autres API/bibliothèques fournissent des équivalents .. qui ne seront pas intégrés au prochain standard, contrairement à ceux de boost)
11/02/2006, 19h47
loufoque

Citation:

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

C'est la technique usuelle.
11/02/2006, 19h51
Progs

Ouais j'ai lu que std::auto_ptr était très déconseillé à l'utilisation dans un vecteur.

Est-ce que boost est présent par default (ou très fréquemment présente) sur les machines linux ?
11/02/2006, 20h01
loufoque

Non ce n'est généralement pas dans l'installation de base mais on peut l'installer via un paquet. (de toutes façons, même gcc n'est pas dans l'installation de base)
11/02/2006, 20h09
Progs

Oui c'est pas faux, mais je voulais dire, trouvé dans la majorité des systems au meme titre que gcc et sa stdlib.
Sinon je suis d'accord, il m'a fallu d'un apt-get pour l'installer :).

Bon par contre je pense que c'est plus source d'emmerde qu'autre chose,
11/02/2006, 20h28
Luc Hermitte

Certains compilos commencent déjà à fournir std::tr1::shared_ptr<> qui est très similaire aux pointeurs intelligents de boost. Il me semble que c'est le cas des dernières versions de GCC.
11/02/2006, 20h29
Progs

Mouais ça ralentit la compatibilité ça :)
12/02/2006, 01h26
loufoque

Citation:

Bon par contre je pense que c'est plus source d'emmerde qu'autre chose

Tu penses mal.

Boost est un élément fondamental de la programmation en C++.
12/02/2006, 11h34
Progs

Je ne parle pas de boost mais des pointeurs intelligents.

Enfin je vais essayer, après tout il me suffit d'un simple
typedef std::vector<boost::shared_ptr<Player>> PlayerVector
pour tester puis si ça merde je remets
typedef std::vector<Player*> PlayerVector
donc bon.

Après comme c'est censé etre bien foutu à part supprimer les delete il n'y a aucun changement à faire si ?:)
12/02/2006, 19h29
loufoque

Ben si, il faut modifier tout le code qui se base sur le fait que les éléments de ton vecteur sont des Player*.