Dynamische Datenstrukturen in .NET

[Raffigator]

Moin,

meine Frage ist, wie es im Allgemeinen so aussieht mit dynamischen Datenstrukturen, insbesondere verkettete Listen. Kompilieren lässt sich das ganze ja nur im $UNSAFAMODE ON. Werden solche Strukturen nicht gern gesehen?

Bei mir geht es konkret darum, eine variierende Anzahl an Datensätzen aus Textdateien einzulesen um diese dann hinterher in verschiedenenen Tabellen in der DB zu speichern. Ich würde das ganze gerne erst in verketteten Listen zwischenspeichern und dann die Liste durchgehen und in der DB speichern...oder hat jemand einen besseren Ansatz?

MfG
Raphael

[mkinzler]

Sie basieren ja auf Zeigern, welche man vermeiden sollte

[Phoenix]

Hrm? .NET hat doch nix gegen verkettete Listen :gruebel:

Du musst halt aufpassen, dass Dein Element ein echtes Objekt ist und Du echte Objektreferenzen speicherst und nicht Pointer.

[Raffigator]

@mkinzler: Wieso sind denn Zeiger zu vermeiden?

@Phoenix: Hättest du da zufällig einen kleinen Codeschnipsel? Bin neu in der .NET-Welt und kann mir gerade nicht ganz vorstellen wie das zu implementieren ist...

[mkinzler]

Weil sie auf Speicherstellen weisen, man sollte stattdessen Referenzen verwenden.
Warum schreibst du die DS nicht sofort in die DB?

[Raffigator]

Zitat:

Zitat von mkinzler

Warum schreibst du die DS nicht sofort in die DB?

Das hatte ich zu erst vor, aber gestaltet sich auf Grund des Aufbaus der Datensätze schwierig. Da zu einer Person in einer Firma bspw. Daten ab einem bestimmten Datum gültig sind und auch nur bis zu einem bestimmten Datum. Das Gueltig-bis-Datum kann aber auch erst mehrere Zeilen weiter unten im DS stehen. Dann müsste ich erst wieder den Datensatz aus der DB (da inzwischen andere Daten gespeichert wurden) raussuchen, um dort dann das Datum zu ändern. Ich würde halt gerne erstmal alles einlesen und dann vor dem Speichern in der DB auch noch eine Konsistenprüfung der zwischengespeicherten Werte machen...
Problem ist halt, dass Teile eines DS in verschiedene Tabellen gespeichert werden und nicht alles in einer...

[Phoenix]

Nein, habe ich nicht, denn ich arbeite nicht mit Delphi.NET sondern mit C#, und da gibts bei mir sowas wie ein List<T> :mrgreen:

Aber im Prinzip brauchst Du nur Deinen Datentypen um eine Referenz auf den gleichen Datentypen zu erweitern und auf die packst Du dann das nächste Element oder am Ende eben null.

Wobei.. wäre das nicht mit einem Array leichter zu erreichen?

[Raffigator]

Zitat:

Zitat von Phoenix

Wobei.. wäre das nicht mit einem Array leichter zu erreichen?

Du meinst ein dynamisches Array?

[mkinzler]

Delphi-Quellcode:

arr: array of ...;
...
setLength( arr, <Größe>);

[Raffigator]

Zitat:

Zitat von mkinzler

Delphi-Quellcode:

arr: array of ...;
...
setLength( arr, <Größe>);

Ja, vielleicht ist das wirklich das sinnvollste...ich werde mal in diese Richtung weiter denken

[Elvis]

Zitat:

Zitat von Phoenix

Wobei.. wäre das nicht mit einem Array leichter zu erreichen?

Hmpf? :shock:

Zitat:

Zitat von Raffigator

Zitat:

Zitat von mkinzler

Delphi-Quellcode:

arr: array of ...;
...
setLength( arr, <Größe>);

Ja, vielleicht ist das wirklich das sinnvollste...ich werde mal in diese Richtung weiter denken

Nein, nein und nochmals nein!

• Punkt1: .Net kennt keine dynamischen Arrays
• Punkt2: Was Delphi anstellen muss um sowas zu emulieren ist alles andere als feierlich.
  Es ist sogar ziemlich lahm.

Du brauchst keine Records für die Knoten, da kannst du genauso gut Klassen nehmen.
Records haben in .Net auf'm Heap nix zu suchen, das ist alles andere als performant. (siehe "Boxing" in egal welcher(m) .Net-Doku oder Buch)
btw: Why setlength is evil™
In .Net >= 2.0 gibt es beides: List<T> (array basiert) und Linked<T>.
In 1.1 kannst du also entweder mit der ArrayList arbeiten oder dir schnell eine verkette Liste friemeln. ;)

[Phoenix]

Zitat:

Zitat von Elvis

Zitat:

Zitat von Phoenix

Wobei.. wäre das nicht mit einem Array leichter zu erreichen?

Hmpf? :shock:
[...]
In 1.1 kannst du also entweder mit der ArrayList arbeiten [...]

Was'n nu? Erst schockiert tun und dann das gleiche Vorschlagen? :zwinker:

[Elvis]

Zitat:

Zitat von Phoenix

Was'n nu? Erst schockiert tun und dann das gleiche Vorschlagen? :zwinker:

Zu heiß geduscht, heut' früh? :mrgreen:
Das eine ist ein BCL Klasse, die intern ihre Daten in einem Array verwaltet. (Klassisches verdoppeln wenn Count >= Capacity), das andere taugt höchstens was um sich am generierten IL zu belustigen.
Oder in Delphi-Speak: ArrayList == TList mit Object statt Pointer als Elementtyp.

System.Array ist immutable, will heißen eine Instanz mit 5 Elementen kann nicht plötzlich 6 haben.
Delphi löst das indem es Zwischenvariablen einbaut und alles immer schön hin und her schubst.

[jmit]

Hallo,

Zitat:

Zitat von mkinzler

Sie basieren ja auf Zeigern, welche man vermeiden sollte

Was spricht gegen Zeiger, warum sollte man diese vermeiden?
Sie werden wohl unter Delphi/Pascal nicht so oft verwendet, aber dies ist ja kein Grund diese ganz zu meiden.

Gruß Jörg

[mkinzler]

Zitat:

Was spricht gegen Zeiger, warum sollte man diese vermeiden?

Es get hier um .Net

[Phoenix]

Zitat:

Zitat von jmit

Zitat:

Zitat von mkinzler

Sie basieren ja auf Zeigern, welche man vermeiden sollte

Was spricht gegen Zeiger, warum sollte man diese vermeiden?
Sie werden wohl unter Delphi/Pascal nicht so oft verwendet, aber dies ist ja kein Grund diese ganz zu meiden.

Wir reden hier von Delphi.NET, und das ist nunmal Typsicher. Und bei einem Pointer irgendwo in den Speicher hat man nunmal keine Ahnung, auf was für ein Datentyp da gezeigt wird.

Ergo -> Typunsicher, daher unsicherer Code, und damit nicht im Sinne von .NET.

[ulrich.b]

Zitat:

Zitat von jmit

Was spricht gegen Zeiger, warum sollte man diese vermeiden?
Sie werden wohl unter Delphi/Pascal nicht so oft verwendet, aber dies ist ja kein Grund diese ganz zu meiden.

... um Typsicherheit zu garantieren (Pointer sind nur (Speicher)Adressen und haben keinen Typen).

http://de.wikipedia.org/wiki/Typsicherheit

[Raffigator]

Also ist nun ArrayList das Stichwort? Das ganze sollte natürlich schon performant sein...Da die Listen auch relativ lang werden könnten im Programm, bietet sich dann wohl die ArrayList an, richtig?

[jmit]

Zitat:

Zitat von Phoenix

Zitat:

Zitat von jmit

Zitat:

Zitat von mkinzler

Sie basieren ja auf Zeigern, welche man vermeiden sollte

Was spricht gegen Zeiger, warum sollte man diese vermeiden?
Sie werden wohl unter Delphi/Pascal nicht so oft verwendet, aber dies ist ja kein Grund diese ganz zu meiden.

Wir reden hier von Delphi.NET, und das ist nunmal Typsicher. Und bei einem Pointer irgendwo in den Speicher hat man nunmal keine Ahnung, auf was für ein Datentyp da gezeigt wird.

Ergo -> Typunsicher, daher unsicherer Code, und damit nicht im Sinne von .NET.

Habt ja Recht, sollte genauer lesen.

[Raffigator]

Hmm, ArrayList ist ja gut und schön, aber wie kann ich dort eine Liste von Records erstellen?

Delphi-Quellcode:

...
type 
 TMyRecord = record
    //mehrere Daten
  end;
...
var 
 MyList : ArrayList;
 MyRecord : TMyRecord; 
...
begin
...
 MyList := ArrayList.Create;
 MyList.Add(MyRecord);
...
end;

Lässt sich ja problemlos kompilieren, aber wie kann ich hinterher auf die Daten in meinem Array zugreifen?

MyList[0].RecordTeil funktioniert ja nicht...

[Elvis]

Zitat:

Zitat von Raffigator

Hmm, ArrayList ist ja gut und schön, aber wie kann ich dort eine Liste von Records erstellen?

Am besten gar nicht.
Records machen in .Net nur da Sinn, wo man

1. nicht daran vorbeikommt (P/Invoke) oder
2. sie per-design immer lokal auf dem Stack leben.
3. Pointer gehen nur auf ValueTypes

Ist alles nicht wirklich häufig. ;)

In jedem anderen Fall sind ValueTypes mit Extrakosten verbunden.
Du kannst value types wunderbar wie primitive Werte behandeln, ein Int32 kann vom JIT, je nach Situation, wie ein normaler, nativer Int32 benutzt werden.
Du kannst sie auch wie ein Objekt benutzen, was du hier scheinbar willst. (ArrayList hält System.Object-Referenzen)
Aber letzteres erfordert, dass der Record wert durch Boxing zu einem Referenzwert wird.

Zitat:

Lässt sich ja problemlos kompilieren, aber wie kann ich hinterher auf die Daten in meinem Array zugreifen?
MyList[0].RecordTeil funktioniert ja nicht...

Na Type casting natürlich:

Delphi-Quellcode:

DeinTyp(deineListe[0]).DoSomething();

Wobei du hier aufpassen musst. .Net ist wirklich type safe: Du kannst nicht die Königin auf Int boxen. ;)
Ein type cast á la DeinTyp(wert) gibt dir entweder einen Wert von DeinTyp zurück, oder wenn "wert" sich nicht umwandeln lässt, nil.
wert as DeinTyp wird eine Exception werfen.
Ersteres ist bestimmt Ursache #1 für all die netten "Object reference not set to an instance of an object"-Meldungen, die man so in freier Natur vorfindet. :mgreen: