Réponses
Trop de publicités?
Il est rare, en réalité, que vous ne souhaitez pas utiliser un tableau. Certainement utiliser un List<T> tout moment vous souhaitez ajouter/supprimer des données, depuis le redimensionnement des tableaux est cher. Si vous connaissez les données de longueur fixe, et que vous souhaitez micro-optimiser pour certains très spécifiques raison (après évaluation), puis un tableau peut être utile.
List<T> offre beaucoup plus de fonctionnalités qu'un tableau (bien que LINQ evens un peu), et est presque toujours le bon choix. Sauf pour params arguments, bien sûr ;-p
Comme un contre - List<T> est unidimensionnel; où-comme vous avez rectangulaire (etc) des tableaux comme int[,] ou string[,,] - mais il existe d'autres moyens de modélisation de ces données (si vous en avez besoin) dans un modèle objet.
Voir aussi:
- Comment/Quand à abandonner l'utilisation de Tableaux dans c#.net?
- Les tableaux, Ce qui est le point?
Cela dit, je fais beaucoup de l'utilisation de tableaux dans mon protobuf-net du projet; entièrement pour la performance:
- il fait beaucoup de décalage de bits, donc un byte[] est à peu près indispensable pour l'encodage
- J'utilise un local roulant
byte[]tampon que je remplis avant de les envoyer vers le flux sous-jacent (et v. v.); plus rapide que l'BufferedStreametc - il utilise en interne un tableau basée sur le modèle d'objets (
Foo[]plutôt que d'List<Foo>), puisque la taille est fixe une fois construit, et doit être très rapide
Mais c'est certainement une exception; pour la ligne générale de traitement des affaires, List<T> gagne à chaque fois.
Vraiment juste répondre à ajouter un lien qui m’étonne n’a pas été mentionné encore : entrée de blog Lippert d’Eric sur » matrices « considéré comme un peu dangereux.
Vous pouvez juger du titre qu’il suggère l’utilisation de collections lorsque cela est possible - mais comme le souligne très justement Marc, il y a beaucoup d’endroits où un tableau est vraiment la seule solution pratique.
Utiliser un tableau lorsque vous traitez avec des données qui sont:
- fixe la taille, ou a peu de chances de se développer beaucoup
- assez grande (plus de 10, 50, 100 éléments, en fonction de l'algorithme)
- vous allez faire beaucoup d'indexation, par exemple, vous savez que vous voudrez souvent le troisième élément, ou le cinquième, ou quoi que ce soit.
Utiliser une liste pour:
- la longueur variable des listes de données
- qui sont principalement utilisés comme une pile ou une file d'attente ou un besoin d'être répétées dans son intégralité
- lorsque vous ne voulez pas écrire une expression pour tirer l'ultime tableau de taille pour la déclaration et vous ne voulez pas inutilement choisir un grand nombre
Utiliser une table de hachage pour:
- la longueur variable des listes de données
- qui doivent être indexés comme une matrice
En réalité, vous aurez envie d'une liste ou d'une table de hachage presque tout le temps. La prochaine fois que vous prenez une structure de données, pensez à ce qu'il doit faire bien pour vous (ou votre code, de toute façon). Ensuite, choisissez quelque chose sur cette base. En cas de doute, choisissez quelque chose d'aussi général que possible, c'est à dire une interface vous pouvez remplacer la mise en œuvre de tout à fait facilement. Quelques bons liens dans les autres réponses.
À moins que vous sont vraiment concernés avec l’exécution et par que je veux dire, « Pourquoi vous utilisez .net au lieu de C++ ? » vous devriez coller avec la liste . Il est plus facile à entretenir et fait tout le sale boulot de redimensionnement d’un tableau dans les coulisses pour vous. (Si nécessaire, la liste est futée sur le choix des tailles de pile donc il ne devrait normalement.)
