Dynamisches Array in Visual Basic.net?

[Geldmann3]

Hallo, ich schreibe gerade ein Programm, in dem am Anfang ein Array erstellt wird.
Dim Super() As Decimal
Ich weiß noch nicht, wie viele Einträge es später speichern soll.

Später möchte ich den Durchschnitt des Arrays anzeigen.
Super.Average

Allerdings bekomme ich eine Fehlermeldung, wenn ich nicht schon von Anfang an angebe, wie viele Einträge das Array bekommen soll.

So zum Beispiel geht es
Dim Super(500) As Decimal

Jedoch kann ich ja nicht einfach schon zu beginn 500 Plätze festlegen, angenommen am Ende werden nur 5 beschrieben, dann bekomme ich mit
"Average" einen falschen Wert heraus.

Hat jemand eine Lösung? Danke

Edit: Habe das Problem gelöst, indem ich das Array mit "ReDim Super(Anzahl)" anpasse, kurz bevor ich weiß, wie viele Werte einzutragen sind.

[Kenny1702]

Gibt es einen bestimmten Grund, warum es ein Array sein muss?
Ansonsten kannst du auch einfach eine typisierte Liste (http://msdn.microsoft.com/de-de/library/vstudio/6sh2ey19.aspx?cs-save-lang=1&cs-lang=vb#code-snippet-1) benutzen. Dort ist dann das ReDim überflüssig.

[FlashBFE]

ReDim ist langsam. Das kann man nehmen, wenn es nur einmal benutzt wird und es nicht auf Performance ankommt. Wenn man den Arrayinhalt behalten will, der schon drin steht, sollte man ReDim Preserve schreiben. Diese Schlüsselworte sind aber eigentlich nur noch zur Kompatibilität drin, das sollte man nicht vergessen. Die elegantere und, wenn das Array normalerweise gleich groß bleibt, schneller Methode ist dagegen die .NET- Funktion: Array.Resize()

Für das Problem, dass man eine Anzahl Elemente vorher noch nicht kennt, ist aber die Liste mit Abstand das beste und schnellste:
Private Sub Button_Click(sender As Object, e As RoutedEventArgs)
'Stark typisierte Liste erstellen
Dim Super As New List(Of Decimal)
'Listenelement hinzufügen
Super.Add(123D)
'Durchschnitt
Dim Durchschnitt = Super.Average
'Und, falls man es doch wieder als Array braucht
Dim SuperArray = Super.ToArray
End Sub

[Gast]

ReDim wurde damals eingeführt, um mit VB6 halbwegs kompatibel zu bleiben, sollte aber nicht mehr benutzt werden.

Hier die typischen Lösungswege für die meisten Anwendungsfälle:
1.) Man kennte die Anzahl => Array
2.) Man kennt die Anzahl noch nicht => Array einfach erst dann deklarieren, wenn die Anzahl bekannt ist.
3.) Man kennt die Anzahl nicht und will Element für Element speichern => List(Of T) verwenden
4.) Man will die Elemente speichern und gleichzeitig prüfen, ob das Element schon vorhanden ist => Dictionary(Of TKey,TValue) verwenden, wobei man hier auch einfach nur die Keys verwenden kann, wenn man keinen Value hat.
5.) Man will Elemente hinzufügen, die man anschließend der Reihe nach wieder verarbeitet => Queue(Of T) verwenden
6.) Bei wachsenden Strings sollte man vielleicht noch die StringBuilder Klasse erwähnen.

Ich verwende VB.NET seit über 5 Jahren ziemlich durchgehend und habe auch schon um die 50.000 Codezeilen damit produziert und ich habe bisher noch keine einzige Anwendung für das Vergrößern/Verkleinern von Arrays gehabt. Zu 99% kommt man mit den oben genannten Kontrukten aus, teilweise verschachtelt z.B. Dictionary(Of String, List(Of MyClass)).

Den Datentyp Decimal habe ich bisher auch noch nie gebraucht. Mit Double kommt man in der Regel aus.

Von der Verwendung der Average Methode würde ich auch generell abraten. Diese wurde erst mit .NET Framework 3.5 eingeführt d.h. man muss die Targetversion auch mindestens auf 3.5 stellen. Wenn es keine sonstigen wichtigen Features gibt, die man benötigt, wo würde ich die Targetplattform auf .NET 2.0 stellen. Das spart bei der Installation schon einmal ca. 200MB bzw. bei älteren XP Rechnern oft fast eine halbe Stunde, bis das installiert ist. .NET Framework 2.0 hat in den meisten Fällen schon jeder installiert.

[Monger]

Ich verwende VB.NET seit über 5 Jahren ziemlich durchgehend und habe auch schon um die 50.000 Codezeilen damit produziert und ich habe bisher noch keine einzige Anwendung für das Vergrößern/Verkleinern von Arrays gehabt.

Das kann ich nur unterstreichen. ReDim ist eh eine rein VB-spezifische Unsitte, und de facto wird da auch nichts anderes gemacht als ein neues Array zu instanziieren, alle Inhalte rüberzukopieren und das alte zu verwerfen. Gerade das umkopieren kann bei größeren Arrays ziemlich viel Zeit in Anspruch nehmen. List(of T) macht das zwar im Prinzip intern auch nicht anders, aber wesentlich intelligenter.

Außer für die paar .NET Funktionen die explizit Arrays und nicht IEnumerable als Übergabeparameter erwarten, würde ich eh soweit gehen zu sagen: vergiss einfach dass es Arrays gibt. Der Ottonormalverbraucher nimmt am besten List(of T). Damit vermeidet man sich ganz allgemein eine Menge Ärger.


Den Datentyp Decimal habe ich bisher auch noch nie gebraucht. Mit Double kommt man in der Regel aus.

Das ist Äpfel mit Birnen verglichen. Beide Datentypen haben deutlich unterschiedliche Anwendungszwecke. Für Finanzmathematische Operationen z.B. wäre es fatal Double zu nehmen.


Von der Verwendung der Average Methode würde ich auch generell abraten. Diese wurde erst mit .NET Framework 3.5 eingeführt d.h. man muss die Targetversion auch mindestens auf 3.5 stellen...
Halte ich ehrlich gesagt für ein schwaches Argument. Meines Wissens ist spätestens seit Win XP SP2 .NET 3.5 eh drin. In Windows 7 ist es eh Standard, und in Win8 ist alles unterhalb .NET 4.0 schon gar nicht mehr standardmäßig mit drin.

Die Spracherweiterungen von .NET 3.5 sind die Mühe allemal wert. Was sich da geändert hat, gerade im Bereich Collections, würde ich heute nicht mehr missen wollen.

[Exxtreme]

Den Datentyp Decimal habe ich bisher auch noch nie gebraucht. Mit Double kommt man in der Regel aus.

Dezimal braucht man für Dinge wie Rechnungen oder allgemein für Dinge rund ums Thema Geld. Und nein, ich würde das nicht unterschätzen. Es kann passieren, dass plötzlich die Steuerfahndung vor der Tür steht. ;)

[FlashBFE]

Von der Verwendung der Average Methode würde ich auch generell abraten. Diese wurde erst mit .NET Framework 3.5 eingeführt d.h. man muss die Targetversion auch mindestens auf 3.5 stellen. Wenn es keine sonstigen wichtigen Features gibt, die man benötigt, wo würde ich die Targetplattform auf .NET 2.0 stellen. Das spart bei der Installation schon einmal ca. 200MB bzw. bei älteren XP Rechnern oft fast eine halbe Stunde, bis das installiert ist. .NET Framework 2.0 hat in den meisten Fällen schon jeder installiert.
Die Spracherweiterungen von .NET 3.5 sind die Mühe allemal wert. Was sich da geändert hat, gerade im Bereich Collections, würde ich heute nicht mehr missen wollen.
Ich frage mich da auch, wieso man heute noch für .NET 2.0 programmieren soll, obwohl schon XP bis 4.0 unterstützt. Die Installationszeit des Frameworks ist doch kein Argument, wenn man dann als Entwickler doppelt so lange braucht, weil man hilfreiche Funktionen nicht zur Verfügung hat. Ich habe alle meine Projekte nach und nach mindestens auf 4.0 umgestellt. Mir kommt es da vor allem auf die TPL (Task Parallel Library) an, ohne die ich heute keine rechenintensiven Programme mehr schreiben möchte.

Einem aktuellen Anfänger jedenfalls dazu zu raten, die völlig veraltete 2.0 zu verwenden, finde ich jedenfalls schon fast bösartig.

[PatkIllA]

4.) Man will die Elemente speichern und gleichzeitig prüfen, ob das Element schon vorhanden ist => Dictionary(Of TKey,TValue) verwenden, wobei man hier auch einfach nur die Keys verwenden kann, wenn man keinen Value hat.Und wenn man sich nicht unnötig auf 2.0 beschränkt hat man ein Hashset.
5.) Man will Elemente hinzufügen, die man anschließend der Reihe nach wieder verarbeitet => Queue(Of T) verwendenWenn man das hinzufügen und verarbeiten nacheinander macht braucht man keine Queue. Queue gehört zu den Collections, die ich fast nie brauche.
Ich verwende VB.NET seit über 5 Jahren ziemlich durchgehend und habe auch schon um die 50.000 Codezeilen damit produziert und ich habe bisher noch keine einzige Anwendung für das Vergrößern/Verkleinern von Arrays gehabt.Man spart noch ein paar Objekte, wenn man direkt ein Array nimmt. Sehr viele der Datenstrukturen verwenden intern auch Arrays und kopieren die bei Bedarf um.
Bei vielen Dingen braucht man auch überhaupt keine richtige Collection sondern kann mit Linq arbeiten oder selbst Iteratoren schreiben.

Von der Verwendung der Average Methode würde ich auch generell abraten. Diese wurde erst mit .NET Framework 3.5 eingeführt d.h. man muss die Targetversion auch mindestens auf 3.5 stellen. Wenn es keine sonstigen wichtigen Features gibt, die man benötigt, wo würde ich die Targetplattform auf .NET 2.0 stellen. Das spart bei der Installation schon einmal ca. 200MB bzw. bei älteren XP Rechnern oft fast eine halbe Stunde, bis das installiert ist. .NET Framework 2.0 hat in den meisten Fällen schon jeder installiert.TPL, Linq, WPF, Extensionmethods, Lambda-Ausdrücke.

[Matrix316]

ArrayList
http://msdn.microsoft.com/de-de/library/system.collections.arraylist%28v=vs.80%29.aspx

[PatkIllA]

ArrayList
http://msdn.microsoft.com/de-de/library/system.collections.arraylist%28v=vs.80%29.aspx
Die kann man als obsolet betrachten.

[Matrix316]

So lange es existiert, so lange es funktioniert, so lange kann man es verwenden. ;)

[RattuS]

Ich lese hier teils Halbwahrheiten. Mit einer generischen Liste umgeht man Redimensionierung keinesfalls, sie alloziert initial lediglich schon mal etwas mehr Speicher (Kapazität) und verdoppelt eigenständig beim Überschreiten. Ein manuelles ReDim ist also durchaus angemessen, wenn man die Kapazität nicht unnötig dehnen möchte. Natürlich ist häufiges manuelles Redimensionieren genau so unsinnig. Es kommt eben auf den Anwendungsfall an. Aber ja, im Regelfall interessiert es bei .NET-Anwendungen niemand, ob ein paar Bytes Überhang sind oder nicht.

[Monger]

Ich lese hier teils Halbwahrheiten. Mit einer generischen Liste umgeht man Redimensionierung keinesfalls, sie alloziert initial lediglich schon mal etwas mehr Speicher (Kapazität) und verdoppelt eigenständig beim Überschreiten. Ein manuelles ReDim ist also durchaus angemessen, wenn man die Kapazität nicht unnötig dehnen möchte.

:facepalm:
Gehörst du etwa auch der Kaste an Programmierern an, die IF Bedingungen durch GOTOs ersetzen um Performance zu sparen?

Der TS wusste zum Erstellungszeitpunkt offenbar nicht mal was von List<T> , und du kommst jetzt mit irgendwelchen bizarren Optimierungszenarien.

Was Performance angeht, in .NET gilt die Philosophie: Speicher ist billig, CPU ist teuer. Das entspricht in 99% der Fälle auch der Wahrheit. Und wenn du einmal ein ReDim auf einem Array machst, ist die Wahrscheinlichkeit groß dass du es bald wieder tust. Dass List<T> lieber etwas Speicher verschwendet als ständig Arrays umzukopieren, ist deshalb vollkommen vernünftig.

[RattuS]

Gehörst du etwa auch der Kaste an Programmierern an, die IF Bedingungen durch GOTOs ersetzen um Performance zu sparen?
Nein, aber ich gehöre zu denen, die sich gerne bewusst machen wie der Zauberkasten .NET intern funktioniert. Einsteigern die komfortabelste Variante zu empfehlen und nie über den Unterschied aufzuklären, mündet in "Generation Java".

In meinem Beitrag kläre ich lediglich auf, worin der Unterschied liegt. Ich empfehle dem TS nicht die ReDim-Variante, sondern die Collections. Aber schließlich kam der TS mit der Dim/ReDim-Idee und da ist es nur fair den Unterschied zu verdeutlichen.

Übrigens ist das von mir beschriebene Optimierungsszenario von uns bei der Entwicklung einer graphorientierten Sprache in der Metrik (Knoten/Kanten) praktisch umgesetzt worden. Es gibt nämlich auch Anwendungen, die viel Speicher brauchen, lieber Monger. :facepalm:

[Matrix316]

Nein, aber ich gehöre zu denen, die sich gerne bewusst machen wie der Zauberkasten .NET intern funktioniert. Einsteigern die komfortabelste Variante zu empfehlen und nie über den Unterschied aufzuklären, mündet in "Generation Java".
[...]

C# und Visual Basic IST mittlerweile wie Java. Das ist das Ziel, dass es nicht so kompliziert und komplex und umständlich wie c++ ist.

Ich nutze doch keine komfortable Programmiersprache nur um alles trotzdem kompliziert programmieren zu müssen.:freak:

[PatkIllA]

Ich nutze doch keine komfortable Programmiersprache nur um alles trotzdem kompliziert programmieren zu müssen.:freak:
Aber die nicht generische ArrayList empfehlen *SCNR*
Außerdem kann es nie schaden auch mal zu schauen, wie es intern funktioniert.

Ich nutze an manchen Stellen auch Arrays um etwas Speicher zu sparen. Oder weil es dafür die meisten Hilfsfunktionnen gibt. Das umkopieren,wenn es zu klein wird hat man ja auch mit einer Zeile (Array.Resize) selbst gemacht. Man darf es halt nur nicht bei jedem Element machen.
Oder wenn man aus API-Gründen IEnumerable zurückgeben muss, man aber nur ein Element zurückgibt.

[Gast]

Ich frage mich da auch, wieso man heute noch für .NET 2.0 programmieren soll, obwohl schon XP bis 4.0 unterstützt. Die Installationszeit des Frameworks ist doch kein Argument, wenn man dann als Entwickler doppelt so lange braucht, weil man hilfreiche Funktionen nicht zur Verfügung hat. Ich habe alle meine Projekte nach und nach mindestens auf 4.0 umgestellt. Mir kommt es da vor allem auf die TPL (Task Parallel Library) an, ohne die ich heute keine rechenintensiven Programme mehr schreiben möchte.

Wenn man sowieso nur für sich alleine bzw. firmenintern für die eigenen Rechner programmiert, dann ist die Installationszeit egal. Wenn man das Ding aber an eine größere Zahl an Kunden verkaufen will und selbst installiert, so ist das ein großes Thema. Das nächste Problem ist, dass man in vielen Fällen komplett ohne Installer bzw. Adminrechte auskommt und die Software einfach so ausliefern kann. .NET 2.0 ist in der Regel schon so gut wie überall installiert. Dazu kommt noch das Problem, dass die Installation von .NET 3.5 ein tieferer Eingriff in das System des Kunden ist, was auch einige Probleme mit sich bringen kann, wenn irgendetwas anderes anschließend nicht mehr läuft. Ich habe auch schon 2 Installation gehabt (intern), wie die Installation von .NET 3.5 schief gelaufen ist und ohne Systemwiederherstellung war überhaupt nichts mehr zu machen.

Wenn man wirklich nur den halben Entwicklungsaufwand hat, dann macht es sich Sinn auf eine neuere .NET Version zu setzen. Das ist zumindest bei mir absolut nicht der Fall. Da waren es bisher nur kleine Nice to haves, bei denen die .NET 2.0 kompatible Lösung jedoch im Endeffekt doch langfristig die bessere Version war.

Einem aktuellen Anfänger jedenfalls dazu zu raten, die völlig veraltete 2.0 zu verwenden, finde ich jedenfalls schon fast bösartig.

Ich halte es für bösartig einen Anfänger nicht über die .NET Versionen aufzuklären. 99% der Anfänger brauchen keine einzige .NET 3.5 Funktion, liefern den Code jedoch für 4.0 und höher aus und wenn das Programm dann einmal die eigene Entwicklungsumgebung verlassen soll, dass kommen die großen Kopfschmerzen, warum es wo nicht läuft. Die Systemvoraussetzungen zu kennen ist eine Grundbedingung dafür, dass man überhaupt mit einer Sprache anfängt, zumindest wenn der Plan besteht, diese auch irgendwann produktiv einzusetzen.

Und wenn man sich nicht unnötig auf 2.0 beschränkt hat man ein Hashset.

Und das kann dann genau was mehr? Dafür kann man dann wieder zig Hilfsfunktionen umschreiben, die auch Dictionarys verarbeiten sollen.

Wenn man das hinzufügen und verarbeiten nacheinander macht braucht man keine Queue. Queue gehört zu den Collections, die ich fast nie brauche.

Stimmt war etwas falsch ausgedrückt. Ich meinte damit abwechselnd Daten hineinstopft und dann ausliest. Das ist für die Verarbeitungs von Jobs über Threads mehr als praktisch (man sollte threadübergreifend natürlich die Synchronized Version verwenden).

Man spart noch ein paar Objekte, wenn man direkt ein Array nimmt. Sehr viele der Datenstrukturen verwenden intern auch Arrays und kopieren die bei Bedarf um.

Nur ist die Logik hier weitaus ausgefeilter. Dass eine List auch einmal intern ein ReDim durchführen muss ist klar, nur nicht bei jedem Element. CPU Zeit/Speicher ist meistens mehr als genug vorhanden. Man sollte nur keinen Code produzieren, dessen Laufzeit quadratisch mit der Anzahl an Elementen skaliert. Das wird dann schnell einmal sehr böse.

Bei vielen Dingen braucht man auch überhaupt keine richtige Collection sondern kann mit Linq arbeiten oder selbst Iteratoren schreiben.

Ich habe 2008 testweise einmal mit einem Projekt intensiv LINQ eingesetzt, habe es dann für die Zukunft aber schnell wieder bleiben lassen. LINQ ist gut dafür geeignet um interne Operationen zu verkürzen. So kann man schnell aus 20 Zeilen nur 5 machen, jedoch führt es auch stark dazu, dass man nur mehr abstrakte Datentypen in der Hand hat, wodurch sich der Code nur mehr sehr schlecht in einzelne Funktionen zerlegen lässt, ohne dass man bei der Laufzeit auf Unmengen an Fehlern stößt, wenn Datenformate nicht passen. Bei klassischer Programmierung schlägt hier immer der Compiler an.

TPL, Linq, WPF, Extensionmethods, Lambda-Ausdrücke.

.) TPL habe ich noch nie benötigt. Multi Core Optimierungen machen meistens mehr Aufwand, als sie bringen und für Hintergrundaufgaben gibt es Threads.
.) LINQ siehe oben
.) WPF verwende ich nicht, sondern lediglich klassische Windows Forms. Sehe da nicht wirklich einen Vorteil, zumindest für meinen Anwendungsbereich. Für die Webentwicklung mag es ein Vorteil sein, aber da ist das mit .NET 3.5 sowieso kein Problem, da alles über einen Server läuft.
.) Extension Methods sind auch nur in Ausnahmefällen sinnvoll. Entweder ist es eine Methode, die zu der Klasse gehört, wo man sie anhängt. Dann sollte sie dort implementiert werden oder sie gehört nicht dazu z.B. irgendeine Hilfsfunktion, die einen String als Parameter erwartet. Diese sollte dann auch nicht an die Klasse angehängt werden, mit der sie eigentlich nichts zu tun hat. Das führt bei größeren Mengen an Code schnell einmal zu Namenskonflikten. Da mache ich lieber eine Utilities Klasse in einem verschachtelten Namespace, die nur statische Methoden enthält, die alles als Parameter akzeptieren im guten alten C Stil.

Ich lese hier teils Halbwahrheiten. Mit einer generischen Liste umgeht man Redimensionierung keinesfalls, sie alloziert initial lediglich schon mal etwas mehr Speicher (Kapazität) und verdoppelt eigenständig beim Überschreiten. Ein manuelles ReDim ist also durchaus angemessen, wenn man die Kapazität nicht unnötig dehnen möchte. Natürlich ist häufiges manuelles Redimensionieren genau so unsinnig. Es kommt eben auf den Anwendungsfall an. Aber ja, im Regelfall interessiert es bei .NET-Anwendungen niemand, ob ein paar Bytes Überhang sind oder nicht.

Also ich habe bisher immer den Ansatz verfolgt, dass ich bei der Entwicklung nur grob auf die Performance schaue, damit ich keine Algorithmen habe, die quadratisch mit der Datenmenge skalieren. Das macht den Code deutlich übersichtlicher und wartbarer. Wenn die Performance anschließend nicht passt, suche ich mit dem Profiler gezielt nach den Stellen, die lange brauchen (sind meistens nur 2-3 in ein paar 1000 Zeilen Code) und bessere hier nach. Das kann z.B. genauso sein, wie du beschrieben hast. Wenn das aber ein Codeteil ist, der einmalig beim Starten ausgeführt wird und sowieso nur < 1ms dauert, dann werde ich da nicht viel Energie rein stecken.

Dezimal braucht man für Dinge wie Rechnungen oder allgemein für Dinge rund ums Thema Geld. Und nein, ich würde das nicht unterschätzen. Es kann passieren, dass plötzlich die Steuerfahndung vor der Tür steht. ;)

Also beim Thema Geld brauche ich in erster Linie einen Datentyp, der mir auch Zahlen nach dem Komma darstellen kann. Ich muss aber zugeben, dass ich selten mit mehr als 45 Billionen Euro zu tun habe, dass ich da eine Differenz von einem Cent hätte. Klar für wissenschaftliche Anwendungen ist das etwas anderes, aber in 99,9% der Fälle hat man so etwas nicht, sondern nur ein paar kleine handelsübliche Zahlen, unter denen sich der normale Durchschnittsbürger auch etwas vorstellen kann.
Viel wichtiger ist, dass man sich angewöhnt generell keine 16Bit Integer zu verwenden (vor allem mit VB6/VBA ist das sehr verlockend und führt zu Problemen, die meistens erst nach Längerem Betrieb auftreten) bzw. keine Floats (da kommen wirklich schnell einmal Differenzen zu Stande).

[PatkIllA]

Wenn man wirklich nur den halben Entwicklungsaufwand hat, dann macht es sich Sinn auf eine neuere .NET Version zu setzen. Das ist zumindest bei mir absolut nicht der Fall. Da waren es bisher nur kleine Nice to haves, bei denen die .NET 2.0 kompatible Lösung jedoch im Endeffekt doch langfristig die bessere Version war.Wofür braucht man die denn langfristig? Wenn es einmal umgestellt ist und der Kunde die neue Version hat ist doch alles gut.
Die neuen Versionen haben meist auch noch ein paar nette Optimierungen und Fehlerbehebungen. Wenn du .NET 2.0 als Target nimmst musst du eigentlich auch noch die ganzen CLR-Kombinationen testen.

Ich halte es für bösartig einen Anfänger nicht über die .NET Versionen aufzuklären. 99% der Anfänger brauchen keine einzige .NET 3.5 Funktion, liefern den Code jedoch für 4.0 und höher aus und wenn das Programm dann einmal die eigene Entwicklungsumgebung verlassen soll, dass kommen die großen Kopfschmerzen, warum es wo nicht läuft.Der Anfänger wird wohl eher selten solche strategischen Entscheidungen treffen. Wir stellen unsere nächste Version auf 4.5.1 um (bisher 4.0)
Die Systemvoraussetzungen zu kennen ist eine Grundbedingung dafür, dass man überhaupt mit einer Sprache anfängt, zumindest wenn der Plan besteht, diese auch irgendwann produktiv einzusetzen.ACK
Und das kann dann genau was mehr? Dafür kann man dann wieder zig Hilfsfunktionen umschreiben, die auch Dictionarys verarbeiten sollen.Das kann eine ganze Ecke weniger und hat dafür weniger Overhead. Die meisten Hilfsfunktionen hat man doch eh auf IEnumerable<T> oder ICollection<T>.
Nur ist die Logik hier weitaus ausgefeilter. Dass eine List auch einmal intern ein ReDim durchführen muss ist klar, nur nicht bei jedem Element.Passt nicht mehr rein => Größe verdoppeln. Das wars dann fast immer schon.
Ich habe 2008 testweise einmal mit einem Projekt intensiv LINQ eingesetzt, habe es dann für die Zukunft aber schnell wieder bleiben lassen. LINQ ist gut dafür geeignet um interne Operationen zu verkürzen. So kann man schnell aus 20 Zeilen nur 5 machen, jedoch führt es auch stark dazu, dass man nur mehr abstrakte Datentypen in der Hand hat wodurch sich der Code nur mehr sehr schlecht in einzelne Funktionen zerlegen lässt, ohne dass man bei der Laufzeit auf Unmengen an Fehlern stößt, wenn Datenformate nicht passen. Bei klassischer Programmierung schlägt hier immer der Compiler an.da ist nichts abstrakt und es ist immer noch genauso typ sicher wie vorher.
Das Debuggen kann aber in der Tat anstrengender sein.
.) TPL habe ich noch nie benötigt. Multi Core Optimierungen machen meistens mehr Aufwand, als sie bringen und für Hintergrundaufgaben gibt es Threads.TPL ist schneller und einfacher zu benutzen. Eigene Threads erstellen muss man nur sehr selten.
.) WPF verwende ich nicht, sondern lediglich klassische Windows Forms. Sehe da nicht wirklich einen Vorteil, zumindest für meinen Anwendungsbereich.Wenn man da einmal die (recht hohe Einstiegshürde) genommen hat will man kein Forms mehr. Bei WPF will man aber wirklich kein .NET 3.5 sondern mindestens 4.0
.) Extension Methods sind auch nur in Ausnahmefällen sinnvoll. Entweder ist es eine Methode, die zu der Klasse gehört, wo man sie anhängt. Dann sollte sie dort implementiert werden oder sie gehört nicht dazu z.B. irgendeine Hilfsfunktion, die einen String als Parameter erwartet. Diese sollte dann auch nicht an die Klasse angehängt werden, mit der sie eigentlich nichts zu tun hat. Das führt bei größeren Mengen an Code schnell einmal zu Namenskonflikten. Da mache ich lieber eine Utilities Klasse in einem verschachtelten Namespace, die nur statische Methoden enthält, die alles als Parameter akzeptieren im guten alten C Stil.Ich finde sie sehr praktisch für Funktionen auf Interfaces und wenn man die Extension Methods in den gleichen Namespace packt muss man auch nicht so stark befürchten, dass dann jede Hilfsmethode doch wieder von jedem neuimplementiert wird.

Also beim Thema Geld brauche ich in erster Linie einen Datentyp, der mir auch Zahlen nach dem Komma darstellen kann. Ich muss aber zugeben, dass ich selten mit mehr als 45 Billionen Euro zu tun habe, dass ich da eine Differenz von einem Cent hätte. Klar für wissenschaftliche Anwendungen ist das etwas anderes, aber in 99,9% der Fälle hat man so etwas nicht, sondern nur ein paar kleine handelsübliche Zahlen, unter denen sich der normale Durchschnittsbürger auch etwas vorstellen kann.Ob klein oder nicht ist egal. Bei Geld will man auf jeden Fall, dass Werte wirklich gleich sind und nicht nur sehr ähnlich. Sonst gehen sämtliche Kontrollrechnungen schief. Und das geht bei double auch in der Praxis noch sehr oft schief.