6
votes

ASP.NET C # énumère qui et quand?

en C # Il semble y avoir plusieurs listes différentes. Au sommet de ma tête, j'ai pu venir avec un couple, mais je suis sûr qu'il y en a beaucoup plus. XXX

Ma question est quand elle est bénéfique d'utiliser un sur l'autre ?

Plus spécifiquement, je retourne des listes de taille inconnue des fonctions et je me demandais s'il y a une liste particulière qui était meilleure à cela.


0 commentaires

8 Réponses :


1
votes

Généralement, liste d'utilisation. Ne pas utiliser ArrayList; C'est obsolète. Utilisez LinkedList dans les cas rares où vous devez pouvoir ajouter sans redimensionner et ne vous dérangerez pas les frais généraux et la perte d'accès aléatoire.


1 commentaires

Je vais conclure que ceci est un exemple de vote stratégique. Comme c'est intéressant.



2
votes
List<String> Types = new List<String>();
LinkedList<String> Types4 = new LinkedList<String>();
are generic lists, i.e. you define the data type that would go in there which decreased boxing and un-boxing.for difference in list vs linklist, see this --> When should I use a List vs a LinkedListArrayList is a non-generic collection, which can be used to store any type of data type.

1 commentaires

La liste peut également être utilisée pour stocker n'importe quel type de données. Il s'agit donc d'une réponse trompeuse. La liste peut être spécialisée sur un type ou sur objet.



-2
votes

ArrayList est probablement plus petit, sage de mémoire, car il est basé sur un tableau. Il a également un accès aléatoire rapide aux éléments. Cependant, l'ajout ou la suppression de la liste prendra plus de temps. Cela pourrait être accéléré légèrement si l'objet est sur-alloué sous l'hypothèse que vous allez continuer à ajouter. (Cela permettra bien sûr de réduire l'avantage de la mémoire.)

Les autres listes seront légèrement plus grandes (4 à 8 octets plus de mémoire par élément) et auront de mauvais moments d'accès aléatoires. Cependant, il est très rapide d'ajouter ou de supprimer des objets aux extrémités de la liste. En outre, l'utilisation de la mémoire est généralement sur place pour ce dont vous avez besoin.


8 commentaires

En fait, une arracheliste est généralement plus grande car elle est essentiellement une gamme d'objets (au moins pour toute liste de tailles non triviale).


@Luckylindy: Les listes de modèles sont meilleures, bien sûr. Mais la mémoire de la matrice ne sera pas significativement importante, sauf si vous stockez des entiers simples ou des numéros de points flottants. Tout le reste descend de l'objet de toute façon.


Luckylindy est correct: ArrayList ne sera pas plus petit mais sera souvent plus grand.


@Luckylindy, @steven, pouvez-vous indiquer des documents qui appuient vos affirmations?


@Christopher: Pour les types de valeur, la flambée doit les casser et la boîte est toujours plus grande que le contenu. La liste génère une version pour chaque TS de non-référence T. Pour les types de référence, il stocke un pointeur indépendamment, mais la liste évite le coût de la radiographie. En bref, il n'y a pas d'avantage pour l'arraylist et il devrait être cvonnée obsolète.


@Steven, un objet qui descend de l'objet n'a pas besoin d'être encadré, il y a donc une augmentation de la taille. Toute la descente est une considération de vitesse, pas une considération de taille. Quant au reste de ce que vous avez dit, c'est exactement ce que j'ai dit dans ma première réponse à Luckylindy. Je ne promouve pas l'utilisation de l'arraylist, indiquant simplement qu'il n'y a pas d'avantage de taille à la version du modèle lors du stockage des objets réels.


Tous les objets descendent de l'objet; Je pense que ce que vous voulez dire, c'est qu'un objet qui ne descend pas de l'appréciage n'a pas besoin d'être en boîte. C'est vrai, donc l'avantage de la taille n'est que pour les types de valeur.


@Christopher, votre réponse d'origine, ladite arraylist est plus petite et a de meilleurs temps d'accès aléatoire. Je crois que cela a été expliqué comment cela est incorrect.



1
votes

Voir l'article sur Types de collecte couramment utilisés de MSDN pour une liste des différents types de collections à votre disposition et de leurs utilisations prévues.


0 commentaires

2
votes

99% du temps Liste est ce que vous voudrez. Évitez les collections non génériques à tout prix.

Linked LinkedList est utile pour ajouter ou supprimer sans déplacer des objets, bien que vous devez renoncer à un accès aléatoire. Un avantage qu'il a fait est que vous puissiez éliminer les éléments tout en itérant à travers les nœuds.


0 commentaires

2
votes

ArrayList est un agent d'entraînement d'avant les génériques. Il n'y a vraiment aucune raison de les utiliser ... ils sont lents et utilisent plus de mémoire que la liste <>. En général, il n'y a probablement aucune raison d'utiliser une liaison Linked Linked Linked Sauf si vous insérez à mi-parcours à travers de très grandes listes.

La seule chose que vous trouverez dans .NET plus rapidement qu'une liste <> est une matrice fixe ... mais la différence de performance est étonnamment petite.


0 commentaires

1
votes

ArrayList est un type de liste .NET 1.0. est une liste générique introduite avec des génériques de .NET 2.0.

Les listes génériques offrent un meilleur support de temps de compilation. Les listes de génériques sont sécurisées. Vous ne pouvez pas ajouter d'objets de mauvais type. Vous savez quel type de type les objets stockés a. Il n'y a pas de typeckecks et de nappes-classique.

Je ne connais pas les différences de performance.

Cette question dit quelque chose à propos de la différence de liste et de lingedlist.


0 commentaires

1
votes

Comme mentionné, n'utilisez pas ArrayList si possible.

Voici Un peu sur Wikipedia sur les différences entre les tableaux et les listes liées .

en résumé:

Tableaux
  • Accès aléatoire rapide
  • Insertion rapide / Suppression rapide à la fin
  • Bonne localité de mémoire

    Listes liées
    • Insertion / suppression rapide au début
    • Insertion rapide / Suppression rapide à la fin
    • Insertion / suppression rapide au milieu (avec énumérateur)


0 commentaires