Dynamisches Array verschachteln und speichern

[flosoft]

Hallo,

hatte hier in dem Forum schon mal nach einer Baumstruktur aus Objekten gefragt http://www.delphipraxis.net/168719-b...bjectlist.html.
Die für mich zu lösende Aufgabe hat sich in der Zwischenzeit etwas verändert, so dass ich das Ganze nochmal durch den Fleischwolf gedreht habe:
Rausgekommen ist nun eine Lösung mit zwei Records und zwei dynamischen Arrays
Ja, mir ist klar das es da bessere/modernere Ansätze gibt... Mir läuft nur gerade die Zeit weg und ich muss die Version 0.0.0.0.0.0.0.1 bald fertig haben. Deshalb kann ich mich leider z.Z. nicht tiefer in die Objektlisten etc. eindenken
Ausser: Ihr haltet mich mit allen Mitteln davon ab und bringt mich doch wieder zu den Objekten...

Meine konkreten Fragen:
1. Spricht etwas gravierendes gegen die folgende Datenstruktur?

Delphi-Quellcode:

type
  TFTerm = record
    id: Integer;
    FVid: Integer;
    Typ: Integer; // 0 = Dreieck, 1 = Trapez ...
    Name: String;
    RangeMin: Double;
    RangeMax: Double;
    Param1: Double;
    Param2: Double;
    Einheit: String;
  end;

  TFzzV = record
    id: Integer;
    Typ: Integer; // 0 = Eingabe und  1 = Ausgabe
    Name: String;
    RangeXLow: Double;
    RangeXHigh: Double;
    Einheit: String;
    FTArray: Array of TFTerm;
end;

var
  FzzV: Array of TFzzV;

2. Speichern/Laden wird man das wohl am Besten mit einem Stream?


Danke für Eure Meinung

[himitsu]

Dagegen spricht erstmal nix, aber du kannst es vergessen die den TFzzV.Record einfach so in einen Stream oder sonstohin speichern oder kopieren(Move) zu können.

String, dynamische Arrays, Interfaces und teilweise auch Variants sind intern "Pointer", womit man also nicht den Inhalt speichern würde, sondern nur den Zeiger
und wenn man sowas direkt läd/kopiert, dann zerschießt man sich auch die automatische Speicherverwaltung, über welche diese Typen verfügen.


Also jedes Feld einzeln in den speichern oder man geht über die RTTI, bzw. nutz eine Serialisierungs-Lib, welche eventuell ebenfalls mit der RTTI arbeitet.


Der ShortString / String[123] und statische Arrays würden aber auch direkt gehn, da sie komplett im Record liegen, ohne Pointer.

[NickelM]

Das Ding ist du kannst nicht einfach eine dynamischen Array in einem Stream aller
Stream.WriteBuffer(FzzV[0],SizeOf(TFzzV)); speichern, da :
- Dynamischer Array ist nur ein Pointer(Adresse), die eine Größe von 4 Bytes hat.
- Delphi setzt vor dem Pointer vom dynamischen Array, ist die Größe bei SetLength initalisiert Delphi den Speicher für den Pointer vom Dynamischen Array. Ein Dynamischer Array ist nichts anderes als ein Statischer Array auf den du eine Pointer machst. Du kannst deshalb auch auf einen Dynamsichen Array auf Positionen zugreifen, die auserhalb des gesetzen Wertes liegen, ohne das der Compiler zumindest meckert, weil dahinter ein Statischer Array steckt. Nur beim zugriff, greifst du auf einen Speicher zu, der nicht für den Pointer (Dynamischen Array) resaviert ist.

Also du musst das Konzept in folgende Richtig ändern.
- Du musst die ID, die du im TFTerm hast dazuverwenden, den TFTerm den TFzzV zuordnen zukönnen.

Das würde dan etwa so Aussehen:

Delphi-Quellcode:

type
  TFTerm = record
    id: Integer;
    FVid: Integer;
    Typ: Integer; // 0 = Dreieck, 1 = Trapez ...
    Name: String;
    RangeMin: Double;
    RangeMax: Double;
    Param1: Double;
    Param2: Double;
    Einheit: String;
  end;

  TTermArray = array of TFTerm; //Damit der Compiler nicht meckert

  TFzzV = record
    id: Integer;
    Typ: Integer; // 0 = Eingabe und 1 = Ausgabe
    Name: String;
    RangeXLow: Double;
    RangeXHigh: Double;
    Einheit: String;
  end;

  TForm1 = class(TForm)
    Button1: TButton;
    procedure FormCreate(Sender: TObject);
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;
  FzzV: Array of TFzzV;
  TermArray : TTermArray;

implementation

{$R *.dfm}

//Hilfsfunktion, die dir den Count und ganz leicht eine Array zurückbekommst.
function FindTermsZuID(AId : Integer; out ATermArray : TTermArray) : Integer;
var I,NewIndex : Integer;
begin
  Result := 0;
  for I := Low(TermArray) to High(TermArray) do //So hast du direkt den gesammten Array zum druchsuchen
  if TermArray[I].FVid = AId then //Wenn ID übereinstimmt
  begin
    NewIndex := Result; //Zurzeit ist der Count noch 0, da der Erste Eintrag den Index 0 hat nehmen.
    Inc(Result); //Wollen ja den Count haben
    SetLength(ATermArray,Result); //Länge festlegen
    ATermArray[NewIndex] := TermArray[I]; //Zuweisen, bischen unsicher wegen Speicher aber dazukomme ich noch.
  end;
end;

procedure TForm1.Button1Click(Sender: TObject);
var FoundTerms : TTermArray;
    TermsCount,I : Integer;
begin
   TermsCount := FindTermsZuID(5000,FoundTerms);
   if TermsCount > 0 then //Falls wir welche gefunden haben, in diem Fall solten es 2 sein
   begin
     for I := 0 to TermsCount -1 do
     begin
       ShowMessage(IntToStr(FoundTerms[I].id));
     end;
   end;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  SetLength(FzzV,1); //Test array
  FzzV[0].id := 5000; //Als Test
  SetLength(TermArray,2); //Terms als test Festlegen, um den Prinzip zuzeigen.
  TermArray[0].id := 15130; //Term ID, NICHT DIE FzzV ID!!
  TermArray[0].FVid := 5000; //Hier kommt die ID, zu wem der Term gehört.

  TermArray[1].id := 15200; //Term ID, NICHT DIE FzzV ID!!
  TermArray[1].FVid := 5000; //Hier kommt die ID, zu wem der Term gehört.
end;

EDIT : Jemand schneller, egal bin müde und hoffe dass es dafür reicht, was er machen möchte.
JETZT ABER WIRKLICH PENEN MAN MAN MAN!!!!....

Gruß NickelM

[flosoft]

Guten Morgen,

danke für die Hinweise.
@himitsu und @NickieIM: habe das mit dem Speichern schon fast vermutet.
Gut. Werde mir den Ansatz von NickieIM heute anschauen.

...Ich könnte mir auch eine XML-Datei als Speicherlösung vorstellen.
Array-Listen in XML hört sich doch gut an...

[Furtbichler]

Herr, lass ordentliche Bezeichnernamen vom Himmel regnen.

Spendiere den Records jeweils eine LoadFromStream und SaveToStream-Methode. In der Methode liest/schreibst Du jedes Feld einzeln.

Bei Strings schreibst Du zuerst die Länge und dann die Zeichen.

Beim Lesen liest Du zuerst die Länge und liest dann die entsprechende Anzahl von Zeichen.

Zum Speichern des Arrays speicherst Du zuerst die Anzahl und rufst dann für jedes Element seine SaveToStream-Methode auf.

Zum Lesen liest Du die Anzahl, erzeugst das Array und rufst dann für jedes Element des Arrays die LoadFromStream-Methode auf.

[tgvoelker]

Zitat von himitsu:

aber du kannst es vergessen die den TFzzV.Record einfach so in einen Stream

Code:

type PFzzV=^TFzzV;
     PFTerm=^TFTerm;
var pPFzzV:PFzzV;
    pI:LongInt;
    pPFTerm:PFterm;
...

pFzzV:=Pointer(Cardinal(FzzV)+Index*SizeOf(TFzzV));
Stream.Write(pPFzzV^,SizeOf(TFzzV));
For pI:=0To Length(pPFzzV^.FTArray)-1 Do Begin
  pPFTerm:=Pointer(Cardinal(pPFzzV^.FTArray)+pI*SizeOf(TFTerm));
  Stream.Write(pPFTerm^,SizeOf(TFTerm));
End;

[Iwo Asnet]

Und der Inhalt? Strings werden nicht korrekt gespeichert, die in dem Record enthaltenen varianten Arrays sowieso nicht.

Mach es so, wie Furtbichler vorgeschlagen hat. Wahlweise XML, aber das wäre mehr Arbeit, aber dafür besser, wenn Daten hinzukommen oder wegfallen.

Beim normalen (binären) Serialisieren würde ich dem Stream eine Versionsnummer spendieren, um etwaige Änderungen in der Datenreihenfolge oder -Aufkommen über die Versionsnummer zu begegnen.

[tgvoelker]

Zitat von Iwo Asnet:

Strings werden nicht korrekt gespeichert

wohl wahr. Wären als Shortstring zu implementieren.

Zitat von Iwo Asnet:

, die in dem Record enthaltenen varianten Arrays sowieso nicht.

Dafür gibt's die For-Schleife.

[Iwo Asnet]

Zitat von tgvoelker:

Dafür gibt's die For-Schleife.

Das ursprüngliche Datendesign enthielt verschachtelte Arrays in Records. Durch geeignete Speicherfunktionalität, z.B. durch die von mir beschriebene, muss man davon nicht abweichen.

[himitsu]

Zitat von tgvoelker:

Dafür gibt's die For-Schleife.

Gut, aber wie ist es mit dem Auslesen?
Beim Auslesen des records schreibst du einen "defekten" Pointer in den Record, also an die Stelle wo das Array steht.
Sobald du dann versuchst mit SetLength dem array seine größe zuzuweisen, weil du nun ja auch noch dieses befüllen willst, knallt es ganz furchtbar.
OK, man könnte jetzt das Speichermanagement mit wilden Pointeroperationen umgehen und dort diesen internen Pointer anpassen, aber dann doch lieber die Felder einzeln auslesen ... jedenfalls für die Personen, welche keine Ahnung davon haben wie z.b. die dynamischen arrays intern verwaltet werden.