Flexible(re) Ladeprozedur

[Der_Unwissende]

Zitat:

Zitat von Master-of-Magic

Zitat:

Du nimmst einfach einen Alias für den aktuellen Datentypen und gibt ein Array von diesem Typen als Ergebnis des Ladens zurück.
Für die aktuelle Version muss also nur das übergebene Array zurückgegeben werden. Kommt eine neue Version hinzu, erstellst Du den entsprechenden neuen Datentypen und änderst den Alias TAktuellerTyp entsprechend ab.

Ich seh da aber ein Problem: Ich muss für jede Version das komplette Record erstellen. Würde das nicht heißen, ich hab für jede Version den Speicher reserviert? Mir scheint, dass das noch aufwändiger und Speicher fressender ist, als meine bisherige Methode ...

Nein, da habe ich nur nicht deutlich gezeigt, dass das nicht der Fall ist. An sich ist der Weg deinem eigenen Ansatz sehr ähnlich. Es fallen aber die vielen Streams weg. Das Umkopieren vom FileStream in einen MemoryStream kannst Du wie gesagt ohnehin weglassen. Das andere ist die Arbeit mit dem temporären Memorystream. Wenn ich es richtig verstanden habe, liest Du aus dem eigentlichen Stream, konvertierst die Daten, schreibst die konvertierten Daten in den temporären Stream und kopierst die Daten dann wieder in den eigentlichen Stream der dann wieder geladen wird.

Was Du also immer machst ist dreimal kopieren (Lesen aus dem Stream, Schreiben in den temporären Stream und Kopieren des kompletten Stream in den original Stream).
Das Du hier ein Stream-Objekt verwendest liegt sicherlich daran, dass Du damit eine flexible Struktur hast, die sich in der Größe anpassen lässt. Mein Änderungsvorschlag wäre hier, dass Du statt dem temporären Stream einfach ein dynamisches Array verwendest. Dieses legst Du eben dynamisch in der Größe an, die Du benötigst.
Konvertierst Du ein Array vom Typ X nach Typ X+1, dann kannst Du danach das Array vom Typ X frei geben (es wird nicht mehr benötigt). Das ganze machst Du indem Du finalize aufrufst und die Länge des dyn. Arrays wieder auf 0 setzt. Damit belegst Du dann wirklich nur den Speicher, den Du wirklich benötigst. Die Reihenfolge ist übrigens wirklich finalize und dann setLength(.., 0), hatte ich vorher falschrum gepostet.
Damit gewinnst Du einfach nur die Sicherheit des Typs. Es ist eigentlich total analog zu deiner Vorgehensweise, aber vielleicht etwas leichter lesbar als der Umweg über Streams. Natürlich kannst Du auch ein dyn. Array immer in den originalen Stream zurückschreiben (Du brauchst das aber eben nicht!).
Damit ersparst Du Dir vorallem das Lesen und Schreiben in einen Stream und arbeitest automatisch auf dem Speicher (da landet ein dyn. Array immer).

Zitat:

Zitat von Master-of-Magic

@Jelly

Zitat:

Warum hat Gott die objektorientierte Programmierung erfunden.

Ach Gott war das? Ich dachte, das wäre eine Nebenwirkung der Erfindung von C++ & Co. gewesen ... :gruebel:

Na ja, C++ kam nach der Objektorientierung. Ohne es jetzt vollständig wiedergeben zu können (mir ist gerade der Autor entfallen!), der Erfinder des Begriffs OOP sagte (sinngemäß):

Zitat:

Als ich den Begriff Objekt Orientierte Programmierung erfand hatte ich bestimmt nicht an C++ gedacht!

[arnold mueller]

Hallo,

vorweg erst einmal: warum speicherst Du die Daten nicht in einer XML Datei?

Eine andere Möglichkeit sehe ich, indem man die Eckdaten der Struktur ebenfalls im Filestream speichert.

Delphi-Quellcode:

type
  TTyp1 = record
    ...
  end;
  TTyp1Array = Array of TTyp1;

 a := TTyp1Array;

 s := SizeOf(TTyp1);
 l := Length(a);


 stream := TFilesStream.Create(....
 stream.Write(s,SizeOf(a));
 stream.Write(l,SizeOf(l));
 straem.Write(a,s*l);

Wenn man jetzt noch per Definition die Struktur TTyp1 niemals verändert, sondern immer nur erweitert, dann braucht man sich beim Einlesen der Daten keine Gedanken machen.

Die Dateien werden natürlich mit jeder Version größer, aber was geht schon ohne Kompromiss?

-
arno