Stockage dynamique d'éléments: Choix d'un conteneur

Bonjour à tous,

dans le cadre d'un programme de People Tracking, je dois pouvoir stocker un élément "people" (ID de la personne, position dans la salle, etc...) quelque part dans ma mémoire, et pouvoir y accéder. Or, ce tableau ne doit pas avoir une taille fixe, car le nombre de personne est amené à varier en permanence.
Quelle serait donc la structure de stockage idéale dans mon cas?
J'ai déjà fais quelques recherces, dans la FAQ par exemple. Ils proposent un graph pour choisir son conteneur ici: http://c.developpez.com/faq/cpp/?pag...hoix_conteneur. Or, cela m'amène à choisir une structure map, mais ca ne m'aide pas beaucoup, je suis toujours dans la flou, car je n'ai jamais travaillé avec, ni meme entendu parler de cette structure.
Il y a aussi ce topic, qui parle de l'utilisation de listes chainées, mais la discussion porte plus sur le langage C.
http://www.developpez.net/forums/arc...p/t-90414.html

Que me conseilleriez vous? Tableau classique (est-il possible de le redimmensionner proprement?)? Liste chainée? Autre?
Merci d'avance pour votre aide

Pour le tableau classique avec cependant redimensionnement "automatique" (dans le sens ou ce n'est pas toi qui gère ça), il y a std::vector.
Une std::map est tout simplement un tableau associatif.
Pour la liste chainée, tu as std::list.
A toi de voir, selon tes besoins.

Je crois que la structure vector est bien adaptée. Si je comprend bien, si je la définie comme un tableau de 10 éléments, puis que je veux en ajouter un 11ème, la methode push_back alloue la memoire toute seule, c'est bien ca?

En effet.

Citation:

---

Je crois que la structure vector est bien adaptée.

---

Ce qui signifie que tu ne sais pas répondre aux questions simples du graphe sur ce que tu veux.

C'est clair que si t'as besoin d'acceder a une personne par son ID, c'est pas un vector qu'il te faut, c'est clair comme de l'eau de roche.....

non c'est bien une map. trouve un tutorial pour apprendre a l'utiliser.

c'est du genre:

std::map<int, Person*> persons;
persons[2] = new Person(2, "myname", ... )
Person *clickedPerson = persons[2];

...

en plus un Vector aura des pertes de performance si ca s'agrandit de trop, j'avais eu un probleme comme ca avant.

A+

Citation:

---

Envoyé par loufoque

Ce qui signifie que tu ne sais pas répondre aux questions simples du graphe sur ce que tu veux.

---

Au contraire, je sais repondre aux questions simples du graphe, preuve en est:

Citation:

---

cela m'amène à choisir une structure map

---

Mais vu que je n'ai pas besoin de chercher une personne par ID dans mon conteneur, et que le nombre de personne ne devrait pas éxcéder 7 ou 8 je pense, le vector est peut-etre plus adapté voila tout.

Si l'ID se trouvait dans ta classe Personne, il fallait sans doute plus un set.
Bon, si avec un vector, tu t'en sors, tant mieux :)
Pour les pbs de performance pour de gros vecteurs, on peut lui demander de reserver une taille de mémoire importante pour ne pas avoir des copies à tout va, ou utiliser un deque.

Citation:

---

Envoyé par BNS

Au contraire, je sais repondre aux questions simples du graphe

---

Ben justement, la preuve que non.
Ce dont tu as besoin c'est un vector (cf. "Je crois que la structure vector est bien adaptée"), mais comme tu ne sais pas répondre aux questions le graphe te dit que tu as besoin d'une map.

Citation:

---

c'est du genre:

std::map<int, Person*> persons;
persons[2] = new Person(2, "myname", ... )
Person *clickedPerson = persons[2];

---

Oui enfin plutôt std::map<int, Person>.

Citation:

---

Envoyé par loufoque

Oui enfin plutôt std::map<int, Person>.

---

non non Person*
enfin moi je n'utilise quasiment que les pointers.

souvent dans ce cas, on souhaite modifier l'objet qui a ete clické ...

Comment tu fais toi ?

Pointeurs intelligents power :)

quand ca sera standard ....

Bientôt, bientôt !
Dans la prochaine version de Boost, il y aura même des fichiers d'en-têtes spéciaux pour utiliser TR1 en avance.

Citation:

---

Envoyé par epsilon68

non non Person*
enfin moi je n'utilise quasiment que les pointers.

---

Ce qui est bien souvent une mauvaise idée.
De toutes façons il a dit qu'il voulait stocker des personnes, pas les réferencer.

On va simplement dire que ça dépend des classes. Il faut déjà qu'elles soient copiables pour les stocker directement dans les conteneurs, et que leur copie soit légère si on fait beaucoup d'insertion et d'effacement.

Citation:

---

Envoyé par loufoque

Ce qui est bien souvent une mauvaise idée.
De toutes façons il a dit qu'il voulait stocker des personnes, pas les réferencer.

---

t'es bien sur de toi...
tu peux developper un peu ton idée et m'expliquer pourquoi c'est souvent une mauvaise idée ?

Parce qu'au moindre pb, il y a fuite mémoire, je pense que c'est à ça qu'il voulait faire allusion.

... humm
quoi dire de plus ?

sans pointer pas de polymorphisme, rien ...
et on peut s'occuper de la gestion memoire pour ne pas avoir "de fuite"

bizarre ce type de reflexion quand meme ....

les pointers font partie du language et il faut faire avec,
j'ai l'impression que beaucoup de personnes aimeraient bien faire du Java en C++...

desolé...

A+

Dans ce genre de cas, on utilise alors une classe englobante, de préférence, afin de pas rencontrer ces problèmes.

bah oui...
pourtant simple non ? ....

Citation:

---

sans pointer pas de polymorphisme, rien ...

---

Sans pointeur pas de polymorphisme, en effet, mais cela ne signifie pas "rien". Dans le cas présent, il n'y avait a priori aucun élément polymorphe.
Pour cela de toutes façons il existe des solutions comme les conteneurs de boost spécialement conçus pour, ou alors les pointeurs intelligents.

Citation:

---

et on peut s'occuper de la gestion memoire pour ne pas avoir "de fuite"

---

Le seul moyen d'écrire du code exception-safe de manière convenable est d'utiliser les destructeurs.

Citation:

---

les pointers font partie du language et il faut faire avec,

---

Les pointeurs sont une chose à éviter en C++, car ce sont des outils dangereux.
Ils ne sont à utiliser tels quels à mon sens que pour la création de structures de données ou pour des cas sans allocation dynamique.

Citation:

---

j'ai l'impression que beaucoup de personnes aimeraient bien faire du Java en C++...

---

Justement non.
C'est en Java que tout est un pointeur, pas en C++.
Si tu veux faire comme en Java, ce qui devient possible avec un ramasse-miettes, tu gâches un peu les possibilités du C++.

les pointers ne sont pas a eviter bien au contraire, sinon pas de polymorphisme et donc un au revoir a beaucoup d'avantages.

il ne faut pas non plus en avoir peur et simplement en tirer avantage.
les shared_ptr ne sont pas non plus une solution a tout. ils induisent en outre une perte de performance et une augmentation memoire. mimimes dans certains cas, penalisantes pour d'autre.

Je n'ai pas bien compris "Le seul moyen d'écrire du code exception-safe de manière convenable est d'utiliser les destructeurs."

quel rapport avec les pointers ? tu parles peut-etre des auto_ptr ?

Oui je le repete, beaucoup de gens veulent le C++ (pour le prestige?) sans avoir a gerer la memoire (a la Java en fait). Mais le C++ tire sa flexibilité des pointers et de la gestion manuelle de la memoire, c'est ce qui permet de faire au mieux les structures de données.

... mais ce n'est que mon avis, d'apres mon experience.

A+

Citation:

---

les pointers ne sont pas a eviter bien au contraire, sinon pas de polymorphisme et donc un au revoir a beaucoup d'avantages.

---

Les pointeurs sont à éviter parce qu'ils sont dangereux.
Il semble que tu n'aies pas entendu parler des principes de base pour du bon C++ : RAII (Resource Acquisition Is Initialization), SBRM (Scope Bound Resource Management)...

Citation:

---

les shared_ptr ne sont pas non plus une solution a tout. ils induisent en outre une perte de performance et une augmentation memoire. mimimes dans certains cas, penalisantes pour d'autre.

---

Je n'en ai jamais ressenti le besoin, n'ayant pas besoin de ressource dont l'appartenance est partagée par plusieurs objets, mais j'imagine que ça simplifie certains cas, autrement moins triviaux que ceux dont on parle, étant donné que ça introduit un ramasse-miettes déterministe.
De toutes façons je n'ai jamais parlé de ça en particulier. La solution aux conteneurs polymorphes c'est les conteneurs pour pointeurs de boost. Pour d'autres cas on peut avoir besoin de std::auto_ptr ou autre.

Citation:

---

Je n'ai pas bien compris "Le seul moyen d'écrire du code exception-safe de manière convenable est d'utiliser les destructeurs."

---

Peut-être ne sais-tu pas ce qu'est l'exception safety.
Voici donc un extrait de TC++PL [en] qui pourrait t'aider dans ce cas.

Citation:

---

quel rapport avec les pointers ?

---

La mémoire libre allouée avec "new" ne se libère pas toute seule.
Enfin le rapport est tellement évident que je me demande pourquoi tu poses cette question.

Citation:

---

Oui je le repete, beaucoup de gens veulent le C++ (pour le prestige?) sans avoir a gerer la memoire (a la Java en fait).

---

C++ et Java sont des langages différents, et qui donc ont des façons différentes de conceptualiser les choses.
En particulier, la façon de gérer la mémoire y est très différente, surtout avec l'approche que je préconise. Contrairement à la façon d'utiliser des pointeurs et des allocations dynamiques, qui formellement ne différencie que par la non présence d'un ramasse-miettes.

Citation:

---

Mais le C++ tire sa flexibilité des pointers et de la gestion manuelle de la memoire, c'est ce qui permet de faire au mieux les structures de données.

---

Les structures de données ne sont écrites qu'une seule fois, ce n'est pas en ça que consiste le travail du développeur.
Les intérêts du C++ sont sa généralité (conçu pour pouvoir programmer tout et n'importe quoi), sa rapidité, sa sécurité, sa modularité, sa généricité et ses capacités d'abstraction.

on peut discuter des heures comme ca, tu ne dois pas lire mes reponses.

... au final je pense que de conseiller de stoker les objets plutot que des pointers n'est pas un bon conseil.

a+