C# Dynamisches Klassenarray

Ich kann zwar kein C#. Wenn  ich jedoch "c# new array" bei gurgel 
eingebe, sieht das igendwie immer anders aus, als bei dir ;)

Wie oft wird dem Array etwas angehängt? array.Resize() ist 
performancemäßig nicht so der Hit. Dann schon lieber eine verkettete 
Liste mit List<RunData>.

Ich wüsste nicht was in diesem Fall klassischer ist als List<> ;)
Ein normales Array ist in C# eigentlich nicht darauf ausgelegt zu 
wachsen, obwohl es natürlich geht.

Alles zu List<>
https://msdn.microsoft.com/de-de/library/6sh2ey19(v=vs.110).aspx

Das sieht dann so aus:

1

var list = new List<RunData>();

2

list.add(new RunData());

Ja, nimm List<T>. Das ist übrigens keine verkettete Liste, sondern quasi 
ein Array-Wrapper (Zugriff über Index möglich).

Reginald L. schrieb:
> public class ProjectData
> {
>     public ProjectData()
>     {
>         runs = 0;
>     }
>
>     private runs;

Da fehlt der Typ bei runs (und in diesem Kontext wird runs sowieso auf 0 
gesetzt, wenn es sich um einen eingebauten numerischen Wertetypen 
handelt; das musst du nicht explizit machen).

Reginald L. schrieb:
> Danke für den Tipp, ich werde es mir für die Zukunft im Hinterkopf
> behalten! Eine "klassische" Möglichkeit gibt es allerdings nicht oder?

Keine Ahnung was genau du mit "klassisch" meinst, aber List in C# 
würde ich schon so bezeichnen (wie TriHexagon). Das dürfte wohl die am 
häufigsten verwendete Collection sein. Arrays verwendet man aktiv 
praktisch nur, wenn es um "Low-Level-Sachen" geht und man genaue 
Kontrolle über das Resizing etc. benötigt und/oder es schneller als 
schnell sein muss (aber selbst dann schreibt man meist einen Wrapper). 
Also mehr oder weniger analog zu Arrays und std::vector in C++.

Reginald L. schrieb:
>> Wie oft wird dem Array etwas angehängt?
> Ist in dem Fall absolut nicht zeitkritisch.

Selbst wenn es so wäre, sollte man erst testen, denn auf modernen 
Prozessoren sind verkette Listen selbst bei relativ vielen Elementen und 
trotz der wegfallenden Kopiervorgänge und Allokationen entgegen der 
häufig ersten Vermutung oft langsamer.

Zustimmer schrieb:
> trotz der wegfallenden [...] Allokationen

Nachtrag:
Ich meine damit die Größe der angeforderten Speicherblöcke. Die 
Allokationsfrequenz ist bei verketteten Listen natürlich meist deutlich 
höher, da für jedes Element einzeln Speicher reserviert werden muss, 
während bei Array-Wrappern fast immer "vorausgedacht" wird. Aber wenn es 
um Effizienz geht, muss man sowieso testen, da ja die Häufigkeit der 
jeweiligen Operationen (Zugriff, Hinzufügen, Entfernen, ...), die 
Auswirkungen des CPU-Caches etc. eine große Rolle spielen.
Ich füge das nur hinzu, weil ich mich oben ein wenig missverständlich 
ausgedrückt hatte.

Zustimmer schrieb:
> Nachtrag:
> Ich meine damit die Größe der angeforderten Speicherblöcke. Die
> Allokationsfrequenz ist bei verketteten Listen natürlich meist deutlich
> höher, da für jedes Element einzeln Speicher reserviert werden muss,
> während bei Array-Wrappern fast immer "vorausgedacht" wird.

Bei C++ würde ich dir sofort zustimmen. Bei C# bin ich mir da gar nicht 
sicher wie das umgesetzt wird, immerhin wird bei jeder neuen Instanz von 
RunData (Referenztyp) sowieso neuer neuer Speicher vom Heap angefordert, 
allerdings muss auch noch der Zeiger auf das nächste Element irgendwo 
hin, also noch mal Speicher anfordern und dort zwei Zeiger ablegen 
(current, next)? Und ist das normale Array ein Vektor aus Zeigern die 
auf die Elemente zeigen? Hab mich mit C# schon länger nicht mehr 
beschäftigt...

Ansonsten ja, pauschal stimmts natürlich nicht ganz, kommt auf den 
Anwendungsfall an.