Discussion :

[zmatz]

Salut!
J'aurais une petite question toute bete.
Voila j'ai une classe Element qui contient un champ Name par exemple.
Je crée ensuite une List de ces Element ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

List<Element> list1=new List<Element>;

j'ajoute des elements a cette liste

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

list1.add(elem1); etc...

je sais par exemple que tous mes elements ont un nom différent.
Comment faire pour récuperer facilement l'élement qui a le nom "blabla" par exemple sans passer par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
foreach(Element e in list1){
if(e.Name=="blalba")
} etc...

y'a t'il une methode plus "light"?
merci!

[Keihilin]

oui en 2.0 il y a une autre méthode : les Predicates !

(Désolé, je te laisse chercher les détails sur cette technique, je suis un poil pressé...)

Cela dit, au niveau du code MSIL généré, les predicates font exactement ce que fait ta boucle, donc pas la peine de t'embêter si ton besoin se resume à ton exemple.

[cinemania]

Si t'en est a passer par le .NET 2.0 et les prédicats par la meme occasion...
tu va bien t'amuser...

Autant utiliser des classes mieux adaptées à ton besoin... Pour cela tu dispose de deux types de classes.
Les hashtable, et les Dictionary<TKey, TValue> qui permettent de recouvrir en temps minimum un objet par rapport à une clé.

Dans ton cas la clé, c'est le nom, et bien tu aura de la redondance certes, et un peu de mémoire en plus consommé, mais le gain en performance n'est pas négligeable surtout sur des listes qui commence à grossir.

Sur une liste de 1000 éléments on estime le cout moyen de ta recherche à 500 opérations, et maximal a 1000 opérations de comparaisons...
Avec un dictionary ou une hashtable, si l'algorithme de hashage de la clé est correcte, tu peux espérer pour 1000 éléments obtenir ton élément en une seule opération.
De nos jours la mémoire n'est plus le critère principal discriminant, les performances si.
Et une recherche en O(1) est a préférer à une recherche en O(n)

Ensuite si tu veux ne manipuler que la liste des objets contenus... tu peux toujours dans le cas d'un Dictionary utiliser ca :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

foreach (TValue val in m_Dictionary.Values) { ... }

Cependant ce problème n'est pas tellement un problème d'algorithme mais de choix de la structure de donnée adaptée.

Voici quelques indications à l'avenir :
- Les listes et les tableaux sont des structures de stockage avant tout.
Les tableaux peuvent cependant faire de redoutable structure de recherche si la clé est numérique.

- Les Hashtables / Dictionary ... sont des structures dediées à la recherche d'une valeur par une clé. Leur implantation est complexe, souvent lourde, et générallement très consomatrice en mémoire, pour les implantations les plus performantes, mais ce sont de très loins les structures les plus rapides.

- Les arbres : eux ils servent au stockage et à la recherche... générallement on les utilise dans quelques cas particulier et dans des implantations de cluster d'index pour des bases de données, en plus des hashtables.

- Les graphes... les graphes eux permettent tout et rien, c'est la structure de données la plus complexe existante. Elle permet aussi bien de faire de la recherche que du stockage... et surtout du stockage avec des informations complémentaires, exemple: le poid d'une route entre deux noeuds... comme dans le routage dans les réseaux.
Dans les graph il est possible de faire de la recherche par valeur, par clé, par critères très rapide, selon les implantations... Malheureusement il n'y pas d'implantation miracle, et il faut générallement implanter le mécanisme qui ira le mieux aux besoins.

Voila après ca ta deja de quoi aller un peu plus loin dans le choix de tes classes de données.

[zmatz]

ok, merci pour ces réponses