Question sur set::set

Version imprimable

07/09/2006, 12h50
socrate

Question sur set::set
Bonjour

Je suis en train d'utiliser std::set pour gérer un ensemble de personnes. Disons que j'ai une classe personne avec un entier décrivant le numéro de téléphone. J'utilise ce numéro de téléphone comme clé pour comparer deux personnes dans l'ensemble (p1 < p2 <=> p1.tel < p2.tel). J'insère donc les personnes au fur et a mesure avec la méthode insert
Le problème survient lorsqu'une persone change de numéro de téléphone (je simplifie l'écriture)
Code:

1 2 3 iterator i=personnes.find(numéro); if(i != personnes.end()) i->SetNuméro(nouveau_numéro);
Mais la bien sur la personne n'est plus au bon endoit dans l'ensemble.
Je voudrais donc savoir quelle est la meilleure solution selon vous:
-Continuer ainsi, mais en enlevant et en réinsérant l'objet à chaque fois
-Utiliser comme clé quelque chose qui ne change pas (mais ce n'est pas toujours possible...)
07/09/2006, 14h41
Laurent Gomila

S'il n'est pas possible d'avoir une clé constante alors tu n'as pas le choix, il faut retirer puis réinsérer l'élément.
07/09/2006, 14h43
ash.ice.loky

Salut,

Citation:

Envoyé par socrate

Mais la bien sur la personne n'est plus au bon endoit dans l'ensemble.
Je voudrais donc savoir quelle est la meilleure solution selon vous:

Citation:

Envoyé par socrate

-Continuer ainsi, mais en enlevant et en réinsérant l'objet à chaque fois

C'est une methode efficace si tu ne doit pas faire trop de changement.
Dans ton cas, la solution est viable car de tout maniere ton algo est constructif
et non iteratif, du coup tu effectueras cette operation ponctuellement et meme si elle est couteuse en ressource cela ne changeras rien a l'execution du programme.

Citation:

Envoyé par socrate

-Utiliser comme clé quelque chose qui ne change pas (mais ce n'est pas toujours possible...)

La ca depend de toi, si tu veux un annuaire inverser, tu doit prendre le tel pour retrouver la personne correspondante. C'est sur que si tu prends son nom tu es tranquille (quoi que si elle se marie ou divorce) mais ce n'est plus la meme fonction du coup.
07/09/2006, 15h06
koala01

Salut,

L'*idéal*, c'est de gérer tes clés sur base d'une valeur absolument unique et qui ne risque pas de changer (numéro de sécu ou numéro de registre nationnal par exemple).

Meme un algorithme qui créerait un identifiant sur base du nom, du prénom et d'une date de naissance ne serait pas sécuritaire à 100%...

Ne riez pas: je connais une personne qui, s'étonnant de ne pas avoir recu sa déclaration d'impôts s'est entendu répondre "c'est normal, madame, vous êtes morte depuis deux ans"...

Simplement, il y avait deux homonymes, nées à la meme date, et ils s'étaient trompés lors du déces de l'une d'elle...
07/09/2006, 15h10
socrate

Merci pour toutes vos réponses.
En fait le problème est un peu le même que celui des clé primaires des bases de données si je comprends bien
07/09/2006, 18h22
koala01

Citation:

Envoyé par socrate

Merci pour toutes vos réponses.
En fait le problème est un peu le même que celui des clé primaires des bases de données si je comprends bien

Exactement...

Finalement, ce que tu fais, c'est "simplement" "réinventer les bases de données"...

(pour rappel: une base de données n'est pas exclusivement informatique ;) )

Maintenant, rien ne t'empeche, une fois que la personne est identifiée de manière unique et immuable, de créer des index sur les différents champs, mais tu seras toujours confronté au choix épineux entre quelque chose permettant la mise à jour rapide avec une faible redondance, mais une recherche "plus lente" et quelque chose présentant une forte redondance, permettant une recherche rapide mais ralentissant la mise à jour des données...