.NET propose un conteneur de liste générique dont les performances sont presque identiques (voir la question sur les performances des tableaux et des listes). Cependant, ils sont très différents au niveau de l'initialisation.
Les tableaux sont très faciles à initialiser avec une valeur par défaut, et par définition ils ont déjà une certaine taille :
string[] Ar = new string[10];
ce qui permet d'attribuer en toute sécurité des éléments aléatoires, par exemple :
Ar[5]="hello";
avec une liste, les choses sont plus délicates. Je peux voir deux façons de faire la même initialisation, aucune n'est ce qu'on pourrait appeler élégante :
List<string> L = new List<string>(10);
for (int i=0;i<10;i++) L.Add(null);
ou
string[] Ar = new string[10];
List<string> L = new List<string>(Ar);
Quel serait le moyen le plus propre ?
EDIT : Les réponses données jusqu'à présent font référence à la capacité, ce qui est autre chose que de pré-remplir une liste. Par exemple, sur une liste qui vient d'être créée avec une capacité de 10, on ne peut pas faire L[2]="une valeur".
EDIT 2 : Les gens se demandent pourquoi je veux utiliser les listes de cette façon, car ce n'est pas la façon dont elles sont censées être utilisées. Je vois deux raisons :
-
On pourrait argumenter de manière tout à fait convaincante que les listes sont les tableaux de "nouvelle génération", ajoutant de la flexibilité sans presque aucune pénalité. On devrait donc les utiliser par défaut. Je signale qu'elles ne sont peut-être pas aussi faciles à initialiser.
-
Ce que j'écris actuellement est une classe de base offrant une fonctionnalité par défaut dans le cadre d'une structure plus large. Dans la fonctionnalité par défaut que je propose, la taille de la liste est connue à l'avance et j'aurais donc pu utiliser un tableau. Cependant, je veux offrir à n'importe quelle classe de base la possibilité de l'étendre dynamiquement et j'opte donc pour une liste.
1 votes
"EDIT : Les réponses données jusqu'à présent font référence à la capacité, ce qui est autre chose que de pré-remplir une liste. Par exemple, sur une liste qui vient d'être créée avec une capacité de 10, on ne peut pas faire L[2]="somevalue"". Compte tenu de cette modification, vous devriez peut-être reformuler le titre de la question...
0 votes
Mais, quelle est l'utilité de pré-remplir une liste avec des valeurs vides, car c'est ce que le topicstarter essaie de faire ?
0 votes
Frederik : Exactement. Quand cela serait-il nécessaire... jamais ?
1 votes
Si le mappage positionnel est si crucial, ne serait-il pas plus logique d'utiliser un Dictionnaire<int, string> ?
0 votes
@Boaz : Je ne pense pas que vous compreniez les concepts en jeu ici.
0 votes
J'ai fini par utiliser des listes comme celle-ci au lieu de Dictionary<int, string> pour des projets rapides et sales dans Unity parce que les listes fonctionnent immédiatement avec l'inspecteur de Unity.
0 votes
Une pénalité presque nulle n'est pas une pénalité nulle. .NET possède à la fois List et Array pour une raison.
7 votes
List
n'est pas un remplacement pourArray
. Ils résolvent des problèmes distincts. Si vous voulez une taille fixe, vous avez besoin d'uneArray
. Si vous utilisez unList
vous vous trompez.0 votes
"On pourrait argumenter de manière assez convaincante que les listes sont la "prochaine génération" de tableaux, ajoutant de la flexibilité sans presque aucune pénalité" - eh bien on a tort :) pouvez-vous créer une liste multidimensionnelle ? l'équivalent de
string[] s=new string[5,5,5,5,5]
(et non=new string[][][][][]
) - non une liste est une liste si vous voulez la prochaine génération de tableaux, vous devrez la développer.0 votes
Cependant, est-ce que List évite la limite de taille d'un seul objet ou Array ? Ce serait un cas pour utiliser une liste de longueur fixe (puis utiliser le parallélisme pour la remplir).
7 votes
Je trouve toujours exaspérant les réponses qui tentent de marteler des arguments du type "Je ne vois pas pourquoi j'aurais besoin de ...". Cela ne veut dire que ça : vous ne le voyez pas. Cela ne signifie pas nécessairement autre chose. Je respecte le fait que les gens veuillent suggérer de meilleures approches à un problème, mais cela devrait être formulé plus humblement, par exemple : "Êtes-vous sûr d'avoir besoin d'une liste ? Peut-être que si vous nous en disiez plus sur votre problème...". De cette façon, cela devient agréable, engageant, et encourage le PO à améliorer sa question. Soyez un gagnant - soyez humble.
0 votes
Le cas où j'en ai besoin est de travailler avec les contraintes des collections dans MVC. Les champs sont générés en utilisant soit un index, soit ce qui ressemble à un GUID dans le nom/ID du champ HTML :
<input name="Property[0].Property1" />
ou `<input name="Property[ecee9ab3-cc42-423b-95d8-f61ae237832e].Property1" />. Je suis chargé d'ajouter dynamiquement de nouvelles entrées pour les éléments supplémentaires au fur et à mesure qu'ils sont ajoutés, et puisque les index sont utilisés sur le formulaire actuellement et que je ne sais pas si je peux mélanger les index et les GUID, j'opte pour KISS et je me contente de sortir des index supplémentaires. Pour cela, j'ai besoin d'une liste suffisamment grande.0 votes
Les arguments sur cette question sont bizarres. Les gens qui disent "cela va à l'encontre de la raison pour laquelle les listes sont créées" n'ont vraiment aucune imagination. Prenons un exemple : j'ai besoin d'une liste de valeurs par défaut lors de l'initialisation, puis un facteur extérieur vient s'ajouter à la liste immédiatement après.