Verschiedene Arrays! Besser mit Generics?

[Mavarik]

Hallo Zusammen.

Gegeben sein folgende Definition:

Delphi-Quellcode:

    TMyRecordDef = record
                     Feldname : String;
                     Feldtype : TFeldtypen;
                   end;

    TRecordDef   = array of TMyRecordDef;

und z.B. folgende Initialisierung:

Delphi-Quellcode:

Const
   SetupRecord  : array[0..1]  of TMyRecordDef = ((Feldname:'Magic';Feldtype:sqKeyText),
                                                  (Feldname:'Wert';Feldtype:sqText));

Leider muss ich jetzt immer folgendes machen:

Delphi-Quellcode:

  Setlength(FRecordDef,length(SetupRecord));
  Move(SetupRecord[0],FRecordDef[0],Sizeof(SetupRecord)); // Feld der Class

Weil die Typen nicht kompatible sind.

Da gibt es doch sicherlich ne "hübsche" Umgehung durch Generics, oder?

Mavarik

[Daniel]

Wenn Du wirklich eine tiefe Kopie haben möchtest und nicht nur Referenzen durch die Gegend schubsen magst, könntest Du Deinem Record beispielsweise eine Assign()-Methode spendieren, wie man sie etwa auch bei einer TStringList findet.

[Furtbichler]

Ich glaube, das man hier keine Generics verwenden kann. Das von Dir beschriebene Problem ist eine Schwachstelle von Delphi, nämlich das Vorhandensein von zwei scheinbar identischen Datenstrukturen: statisches vs. ein dynamisches Array.

Bei Dir ist ja nur rein zufällig FRecordDef genauso groß wie SetupRecord, ergo solltest du das eine Array in das andere kopieren, ohne das blöde Move zu verwenden, also warum nicht banal?

Delphi-Quellcode:

FRecordDef[0] := SetupRecord[0];
FRecordDef[1] := SetupRecord[1];

oder allgemein:

Delphi-Quellcode:

Procedure InitializeRecordDef(Var recordDef : TRecordDef);
Var
  i : Integer;

Begin
  SetLength (recordDef, Length(SetupRecord));
  for i:= low(SetupRecord) to High(SetupRecord) do recordDef[i]:=SetupRecord[i];
End;

[Mavarik]

Zitat:

Zitat von Furtbichler (Beitrag 1245426)

ergo solltest du das eine Array in das andere kopieren, ohne das blöde Move zu verwenden, also warum nicht banal?

Warum soll ich ne for schleife nehmen, wenn der Move das gleiche macht nur in einem Bruchteil der Zeit?

[Furtbichler]

Zitat:

Zitat von Mavarik (Beitrag 1245429)

Zitat:

Zitat von Furtbichler (Beitrag 1245426)

ergo solltest du das eine Array in das andere kopieren, ohne das blöde Move zu verwenden, also warum nicht banal?

Warum soll ich ne for schleife nehmen, wenn der Move das gleiche macht nur in einem Bruchteil der Zeit?

Logisch, würde ich normalerweise auch so machen (Obwohl das mit dem Bruchteil so ne Sache ist, aber im Prinzip haste Recht). Ich dachte eher an diese perversen String-Referencecounter. Keine Ahnung, ob beim Move dabei alles koscher bleibt.

[Uwe Raabe]

Zitat:

Zitat von Furtbichler (Beitrag 1245437)

Ich dachte eher an diese perversen String-Referencecounter. Keine Ahnung, ob beim Move dabei alles koscher bleibt.

Dachte ich auch erst, aber die Strings sind ja faktisch Konstanten. Konstante Strings haben aber als RefCount immer -1 und der wird auch nicht verändert.

Normalerweise ist der Move-Befehl bei Records mit ref-counted Feldern ein No-Go. Deshalb würde ich ihn auch in diesem speziellen Fall nicht verwenden.

BTW - Man kann es auch so machen:

Delphi-Quellcode:

Procedure InitializeRecordDef(Var recordDef: TRecordDef);
Begin
  recordDef := TRecordDef.Create(SetupRecord[0], SetupRecord[1]);
End;

[himitsu]

Zitat:

Zitat von Mavarik (Beitrag 1245422)

Leider muss ich jetzt immer folgendes machen:

Delphi-Quellcode:

  Setlength(FRecordDef,length(SetupRecord));
  Move(SetupRecord[0],FRecordDef[0],Sizeof(SetupRecord)); // Feld der Class

Nein, das musst du nicht, denn wenn du das machst, dann versohl' ich dir den Arsch! :warn:

Denn du schrottest damit die Referentzählung des

Delphi-Quellcode:

String

.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1245441)

Denn du schrottest damit die Referentzählung des

Delphi-Quellcode:

String

.

Das stimmt eben genau in diesem Fall nicht!

Stringkonstanten haben einen Referenzzähler von -1, der auch nicht verändert wird. Mit dem Move-Befehl wird ja auch nicht der String kopiert, sondern nur der Zeiger darauf. Für den weiteren Programmablauf verhält sich das Stringfeld im Record genauso als ob man die Konstante direkt zugewiesen hätte. Für nicht-konstante Strings hättest du natürlich Recht, weswegen ich diesen Code auch eher als Hack ansehe.

Du kannst Mavarik also unbehelligt lassen... (obwohl, eine Kopfnuss wäre vielleicht doch angebracht)

[himitsu]

Das ist aber auch nur Zufall, wenn es hier zufällig geht.

FRecordDef muß vorher leer sein, also es darf wirklich nichts in [0] stehen
und in dem SetupRecord müssen "echte" String-Konstanten (RefCount = -1) drin stecken.

Aber seit diesen komischen mobilen Compilern sollte man dem Braten nicht mehr so einfach trauen.
(die haben schon unsere schöne Delphi-1 geschrottet ... wer weiß was die sonst noch machen)


Nja, und wer weiß wo er sonst noch solchen Code verwendet?
Am Ende ist es doch so, daß man später wieder irgendwo sowas braucht, dann copy&pastet man es und schwup, an der Stelle war das dann natürlich zufällig falsch.


InitializeRecord, FinalizeRecord und CopyRecord, bzw. XxxxxxArray mit Anzahl 1 und schon nutzt man die richtigen Methoden, (siehe Unit System)
wenn man ungedingt manuell Kopieren machen will.
Oder man weist direkt die Records via

Delphi-Quellcode:

:=

und überläßt es dem Compiler. Es ist ja nicht so, daß der native Code hier sooooooooooooo lahm wäre.



Hey, nun, wo man endlich Record-Helper auch nativen Typen zuweisen kann, wäre ein

Delphi-Quellcode:

type
  TRecordDefHelper = record helper for TRecordDef 
    procedure Assign(const Values: array of TMyRecordDef);  // Code siehe InitializeRecordDef in #3
    //procedure Add(...
    //procedure Delete(...
    //...
  end;

FRecordDef.Assign(SetupRecord);

doch ganz nett? (geht aber erst seit XE4 oder so :cry:)

[Mavarik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1245440)

Delphi-Quellcode:

Procedure InitializeRecordDef(Var recordDef: TRecordDef);
Begin
  recordDef := TRecordDef.Create(SetupRecord[0], SetupRecord[1]);
End;

Mit den 2 Feldern geht das ja noch... Aber andere Records haben 100 Felder!

[Union]

Dann musst Du eben nicht mit Records arbeiten, sondern mit einer entsprechenden Klasse, die den Puffer anhand einer Objektliste zerpflückt bzw. wieder zusammensetzt.

[DeddyH]

Nun komm doch nicht mit so nem neumodischen Kram. Klasse, *pfh* :mrgreen:

[Mavarik]

das Problem ist doch nicht wie es gespeichert wird...

Sondern wie es definiert ist... Und zwar als Konstanten

[Union]

Dann musst Du eben die Definition ändern. Bisher

Delphi-Quellcode:

TMyRecordDef = record
  Feldname : String;
  Feldtype : TFeldtypen;
end;

Ersetzen durch (ähnlich wie ein Dataset)

Delphi-Quellcode:

TMyRecordDef = class(TRecordDef)
...
MyRecordDef := TMyRecordDef.Create;
MyRecordDef.ID := '';
MyRecordDef.AddDefinition('FeldName', ftString, 20);
MyRecordDef.AddDefinition('Feldtype', TFeldTypen);

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1245541)

Zitat:

Zitat von Uwe Raabe (Beitrag 1245440)

Delphi-Quellcode:

Procedure InitializeRecordDef(Var recordDef: TRecordDef);
Begin
  recordDef := TRecordDef.Create(SetupRecord[0], SetupRecord[1]);
End;

Mit den 2 Feldern geht das ja noch... Aber andere Records haben 100 Felder!

Du kannst natürlich auch die Konstanten direkt in das TRecordDef.Create verlagern. Solange das Konstanten-Array nur dafür benutzt wird daraus dynamische Arrays zu machen, wäre das immerhin auch ein Ansatz.

Delphi-Quellcode:

Procedure InitializeRecordDef(Var recordDef: TRecordDef);
Begin
  recordDef := TRecordDef.Create(
                  (Feldname: 'Magic'; Feldtype: sqKeyText),
                  (Feldname: 'Wert'; Feldtype: sqText));
End;

[Der schöne Günther]

Ich habe es mehrmals versucht und ich habe mir Mühe gegeben, aber ich verstehe immer noch nicht, um was es überhaupt geht :oops:

Man erstellt lokal einen Record (mit vielen Feldern) und möchte ihn nun in einen definierten "Default"-Zustand bringen, oder?

Man kann einem Record doch einen (nicht parameterlosen) Konstruktor verpassen und lässt es dort machen? Und - was ich schon immer fragen wollte - was hat es eigentlich mit dem "Default"-Befehl auf sich? Kann man da etwas anpassen oder festlegen, was Default sein soll?

Delphi-Quellcode:

type
   TMyRecord  = record
      someIntField: Integer;
      someStrField: String;
   end;
var
   myRecord: TMyRecord;
begin
   myRecord := Default(TMyRecord);
   [...]
end;

[himitsu]

Sieh das Default einfach wie ein New, nur ohne Pointer dazwischen.

Wenn man bei einfachen Typen anfängt, wird es vielleicht klarer.

Delphi-Quellcode:

Default(Integer) = 0  // Low(Integer)=MinInt und High(Integer)=MaxInt
Default(String) = ''  // Low(String)=erster Array-Index und High(String)=letzer Array-Index
Default(TButton) = nil

Und das kann man nun verschachteln (

Delphi-Quellcode:

Default(TMyRecord)

),
wobei quasi für jedes Feld des angegebenen Records das Default des entsprechenden Typen eingesetzt wird.
(im Prinzip entspricht es dem InitializeRecord/InitializeArray aus der SysUils)

[Der schöne Günther]

Ja, mir war nur gruselig, dass ich in der Hilfe zu dumm war, überhaupt etwas zum Ausdruck "Default" zu finden und auch keinen RTL-Code. Dass der alle Record-Felder so initialisiert, wie sie es bsp. in einer Klasse wären war mir schon klar. Nur vielleicht ließe sich das auch manuell noch für einen eigenen Record-Typen anpassen? Man weiß ja nie 8-)

[Mavarik]

Zitat:

Zitat von Union (Beitrag 1245550)

Delphi-Quellcode:

TMyRecordDef = class(TRecordDef)
...
MyRecordDef := TMyRecordDef.Create;
MyRecordDef.ID := '';
MyRecordDef.AddDefinition('FeldName', ftString, 20);
MyRecordDef.AddDefinition('Feldtype', TFeldTypen);

So könnte man es sicherlich auch machen.
Dann habe ich aus der Konstantendefinition mit 0 Taktzyklen eine aktive Zuweisung mit 10000n Taktzyklen gemacht.
So mache ich für die Zuweisung einen Move - und bin fertig.
Ich habe von diesen Definitionen ca. 25 in allen größen von Array[0..2] bis Array[0..350].
Da ich im OnCreate meines Datenbank Objects diese Definition setzen muss, müsste ich jedes mal durch so eine Liste laufen.
Sorry, aber Mobile_Apps sind schon langsam genug... Mein Weg funktioniert ja.

Dachte nur man könnte es ggf. etwas schöner machen...

Ich dachte eher sowas wie

DoSetArray<T>(MyRecord:T) irgendetwas... Um die Typenzuweisung hin zu bekommen.

Aber ein Generic Type läßt sich scheinbar auch nicht als Konstante definieren, oder doch?

[Union]

Wie hast Du denn die Taktzyklen auf dem Mobilgerät gemessen? Daran wäre ich auch mal sehr interessiert.

[Furtbichler]

Zitat:

Zitat von Mavarik (Beitrag 1245560)

Dann habe ich aus der Konstantendefinition mit 0 Taktzyklen eine aktive Zuweisung mit 10000n Taktzyklen gemacht.
So mache ich für die Zuweisung einen Move - und bin fertig.

Bau Dir einfach eine Init-Routine, die das Move kapselt. Das sieht gut aus und der einzig unsichere Code ist in einer einzigen Routine. Die kannst du dann noch als unsicher kommentieren und auf die Gefahren hinweisen mit dem Referenzzähler hinweisen und später vielleicht doch sauber umsetzen (auch wenns nen Takt länger dauert):

Delphi-Quellcode:

procedure InitializeRecord(var recordDef : TRecordDef;  const setupData : Array Of TMyRecordDef);
Begin
  Setlength(RecordDef, Length(setupData));
  Move(setupData[0], RecordDef[0], SizeOf(setupData));
End;

Der Trick ist der open array parameter 'Array Of TMyRecordDef'. Das ist hier kein dynamisches Array, sondern eben irgend ein 'Array Of TMyRecordDef'. Der Compiler macht das schon richtig. Und aufrufen geht ganz einfach

Delphi-Quellcode:

Begin
  InitializeRecord (myNewRecordDef, SetupDataWith150Values);
  InitializeRecord (myOtherRecordDef, SetupDataWith2Values);

Das ist genau das, was himitsu schon vorgeschlagen hat.

Übrigens (Tipp): Hör auf mit dem Takte zählen. Auch wenn so ein Mobilteil nicht das schnellste ist (1Ght Takt, pff), *dabei* geht garantiert keine Zeit flöten, sondern eher mit Swapping, Dateizugriffen, schlechten Algorithmen, miesen Datenbankabfragen, schrottigen GUI-Frameworks und dergleichen. Aber ich lass mich natürlich gerne belehren.

[Mavarik]

Zitat:

Zitat von Furtbichler (Beitrag 1245594)

Übrigens (Tipp): Hör auf mit dem Takte zählen. Auch wenn so ein Mobilteil nicht das schnellste ist (1Ght Takt, pff), *dabei* geht garantiert keine Zeit flöten, sondern eher mit Swapping, Dateizugriffen, schlechten Algorithmen, miesen Datenbankabfragen, schrottigen GUI-Frameworks und dergleichen. Aber ich lass mich natürlich gerne belehren.

Nee gerade nicht. Wenn alle mal sich ein bisschen darauf besinnen würden, dass ein Move schneller ist als 100 Zuweisungen und es den Leuten weniger darum gehen würde ob der Code schön aussieht! Hätten wir die gleich Geschwindigkeit z.B. unter Windows mit der halben Taktfrequenz.

Wenn ich mir anschaue wie oft in der RTL etwas erzeugt wird dann der Free um kurz darauf es wieder zu erzeugen. Oder wie oft ein Speicherbereich kopiert wird usw... Gruselig.

Aber Du hast schon Recht. Optimierung hat nicht mehr den Stellenwert wie früher. Nur wenn ich mit wenigen Handgriffen optimieren kann, mach ich das auch.

[DeddyH]

Nichts gegen Optimierung, aber nicht auf Kosten der Sicherheit. Zumindest mir persönlich ist ein Programm lieber, dass etwas langsamer stabil läuft als eins, das etwas schneller abschmiert.