Array versus Liste<T>: Wann ist was zu verwenden?

Question

MyClass[] array;
List<MyClass> list;

Welche Szenarien gibt es, in denen das eine dem anderen vorzuziehen ist? Und warum?

Answer 1

In der Realität ist es selten, dass Sie ein Array verwenden möchten. Verwenden Sie auf jeden Fall ein List<T> jedes Mal, wenn Sie Daten hinzufügen/entfernen wollen, da die Größenänderung von Arrays teuer ist. Wenn Sie wissen, dass die Daten eine feste Länge haben, und Sie eine Mikro-Optimierung für einige sehr spezifisch Grund (nach dem Benchmarking), dann kann ein Array nützlich sein.

List<T> bietet eine Los mehr Funktionalität als ein Array (obwohl LINQ es ein wenig ausgleicht), und ist fast immer die richtige Wahl. Außer für params Argumente, natürlich. ;-p

Als Gegenleistung - List<T> eindimensional ist; wogegen Sie rechteckige (usw.) Arrays haben wie int[,] o string[,,] - aber es gibt andere Möglichkeiten, solche Daten in einem Objektmodell zu modellieren (falls erforderlich).

Siehe auch:

• Wie/Wann kann man die Verwendung von Arrays in c#.net aufgeben?
• Arrays, Was ist der Sinn?

Trotzdem mache ich eine Los der Verwendung von Arrays in meinem protobuf-net Projekt; ausschließlich für Leistung:

• wird eine Menge Bit-Shifting durchgeführt, so dass ein byte[] ist für die Kodierung so gut wie unverzichtbar;
• Ich verwende ein lokales Walzwerk byte[] Puffer, den ich fülle, bevor ich ihn an den zugrunde liegenden Stream (und v.v.) weiterleite; schneller als BufferedStream usw;
• verwendet es intern ein Array-basiertes Modell von Objekten ( Foo[] statt List<Foo> ), da die Größe nach der Erstellung feststeht und sehr schnell sein muss.

Aber das ist definitiv eine Ausnahme; für die allgemeine Geschäftsabwicklung ist eine List<T> gewinnt jedes Mal.

Answer 2

Ich wollte eigentlich nur einen Link hinzufügen, von dem ich überrascht bin, dass er noch nicht erwähnt wurde: Erics Lippert's Blogeintrag über "Arrays gelten als eher schädlich".

Wie Sie dem Titel entnehmen können, wird empfohlen, Sammlungen zu verwenden, wo immer es praktisch ist - aber wie Marc zu Recht betont, gibt es viele Stellen, an denen ein Array wirklich die einzige praktische Lösung ist.

Answer 3

Ungeachtet der anderen Antworten, in denen empfohlen wird List<T> werden Sie bei der Bearbeitung Arrays verwenden wollen:

• Bild-Bitmap-Daten
• andere Datenstrukturen auf niedriger Ebene (z. B. Netzwerkprotokolle)

Answer 4

Wenn Sie sich nicht wirklich Sorgen um die Leistung machen, und damit meine ich: "Warum benutzen Sie .Net und nicht C++?", sollten Sie bei List<> bleiben. Es ist einfacher zu pflegen und erledigt die ganze schmutzige Arbeit der Größenänderung eines Arrays hinter den Kulissen für Sie. (Falls nötig, ist List<> ziemlich schlau bei der Wahl der Array-Größen, so dass es das normalerweise nicht braucht.)

Answer 5

Arrays debe anstelle von List verwendet werden, wenn die Unveränderlichkeit der Sammlung selbst Teil des Vertrags zwischen dem Client- und dem Provider-Code ist (nicht unbedingt die Unveränderlichkeit der Elemente innerhalb der Sammlung) UND wenn IEnumerable nicht geeignet ist.

Zum Beispiel,

var str = "This is a string";
var strChars = str.ToCharArray();  // returns array

Es ist klar, dass eine Änderung von "strChars" das ursprüngliche "str"-Objekt nicht verändert, unabhängig von der Kenntnis des zugrunde liegenden Typs von "str" auf Implementierungsebene.

Aber angenommen, dass

var str = "This is a string";
var strChars = str.ToCharList();  // returns List<char>
strChars.Insert(0, 'X');

In diesem Fall geht aus dem Codeausschnitt allein nicht hervor, ob die Insert-Methode das ursprüngliche "str"-Objekt verändern wird oder nicht. Es erfordert Kenntnisse auf der Implementierungsebene von String, um diese Entscheidung zu treffen, was den Design by Contract-Ansatz bricht. Im Fall von String ist das keine große Sache, aber es kann in fast jedem anderen Fall eine große Sache sein. Das Einstellen der Liste auf schreibgeschützt hilft zwar, führt aber zu Laufzeitfehlern, nicht zur Kompilierzeit.