Wie verwendet man "Unterklassen" am besten?

[p80286]

Hallo zusammen,

ich habe bisher eine mit einer Tlist einige Dateiinformationen verwaltet

Delphi-Quellcode:

type 
  tFileRec=record
             name   : string;
             ext    : string;
             path   : string;
             size   : cardinal;
             lastrd : tdatetime;
             lastwr : tdatetime;
           end;
  pFileRec = ^tFilerec;

Um mir das ewige Typecasting zu erparen hab ich daraus eine Klasse(TMyFiles) gemacht, wobei
.Add und .Items[i] jeweils tFileRec erwartet bzw. liefert, aber FileList[i] gibt einen Pointer zurück.

Wenn ich bisher z.B. mit allen .PAS Dateien etwas machen wollte ging das so ganz gut:

Delphi-Quellcode:

pasFileList:=TList.Create;
if tFileRec(allFileList[i]^).ext='PAS' then
     pasFileList.add(allFileList[i])
....
 { machwas }
  tFileRec(pasFileList[i]^).Name.....
 { machwas Ende} 
 pasFileList.Free;
    {

Danach waren noch alle (Datei)Daten in der allFileList vorhanden, und ich konnte ohne erneutes Einlesen z.B. alle XLS-Dateien verarbeiten.

Kann ich das auch mit TMyFiles erreichen ohne die Krücke Typecasting und Tlist zu nutzen?
Bräuchte ich ggf. zwei Free-Methoden?
eine um die Nutzdaten (records) frei zu geben und eine um die Pointer in den Orcus zu schicken?

Könntet Ihr mir hier auf die Sprünge helfen?

[xZise]

Wird ein Record nicht automatisch freigegeben? Natürlich nicht, wenn du einen Pointer da was mit New zugewiesen hast.

Und ich verstehe dein aktuelles Problem nicht so ganz: Du hast ein TMyFiles was intern eine TList speichert, und du greifst munter mit add und so drauf zu? Dann kannst du doch alles so lassen oder nicht?

MfG
Fabian

[shmia]

Aus dem Record eine Klasse machen und statt einem Array oder TList die Klasse TObjectList verwenden.

Delphi-Quellcode:

tFileObj=class(TPersistent)
public
  name : string;
  ext : string;
  path : string;
  size : cardinal;
  lastrd : tdatetime;
  lastwr : tdatetime;
  function Filename:string;      // liefert name + ext
  function FullFilename:string;  // liefert path + Filename
  procedure LoadFromSearchRec(const sr:TSearchRec); // kopiert Werte aus sr auf name,exe,size,...
  procedure Assign(Source: TPersistent);override;  // sollte man implementieren
end;

Leider gibt es viele Delphi-Programierer die den Schritt vom Record zur Klasse nicht vollziehen.
Ich vermute, dass es unter anderem daran liegt, dass man Objekt explizit freigeben muss.
Wobei hier aber TObjectList zur Hilfe kommt und die Sache angenehmer macht.

[p80286]

Das mit der TObjectlist muß ich mir mal anschauen.

Trotzdem hab ich da immer noch ein Verständnisproblem.
Ich habe eine Klasse die Verwaltungsdaten und die eigentlichen Daten enthält,
und eine zweite Klasse, die nur die Verwaltungsdaten enthält (enthalten soll). So etwas ähnliches wie ein View oder ein Filter. Nach aussen hin sollen sich beide gleich verhalten, wobei die zweite Klasse die erste zwangsläufig vorraussetzt. wenn ich die zweite Klasse "in den Orcus jage" muß die erste allerdings vollständig erhalten bleiben.
Tut mir leid, das ich es nicht besser beschreiben kann . Mir fehlt das richtige Vokabular.

Gruß
K-H

PPs
Ich schlepp noch ein paar Felder mehr mit mir herum, und da stecken noch einige Methoden in der Klasse.

P.S.

Zitat:

Zitat von shmia (Beitrag 1053182)

Ich vermute, dass es unter anderem daran liegt, dass man Objekt explizit freigeben muss.

sobald ich New(pMyRec) verwende, muß ich im Gegenzug Dispose verwenden, das ist nicht das Problem. Für mich ist es eher, warum ein TObject verwenden wenn ein Record bzw. eine Pointer/Record Kombination alles bietet was ich brauche. Glaub ich jedenfalls.

[Sir Rufo]

Du willst doch das TypeCast loswerden ... oder irre ich mich da?

[p80286]

Zitat:

Zitat von Sir Rufo (Beitrag 1053195)

Du willst doch das TypeCast loswerden ... oder irre ich mich da?

Äh, ja! warum?

K-H

[Hansa]

Du bist mit der TList vermutlich wirklich etwas zu kurz gesprungen. 8-) Wie gesagt : TobjectList und OwnsObjects sollte auf true stehen.

@Daniel : wäre gut, wenn man beim Schreiben sehen könnte, welche Delphi-Version eingesetzt wird.

So, der ganze Krempel, den man in die TObjectList packt, wird dann beim free der Liste auch komplettt weggeräumt. Das ist minimaler Aufwand. Du kannst ja sogar auch die Records komplett in die ObjectList packen. Die schluckt fast alles. :shock:

Hier mal noch, wie das ganze ungefähr aussieht :

Delphi-Quellcode:

TArtGrundDaten = record
  ID,
  nr : Integer;
  bez : string;  
// stark verkürzt !!
end;

TDatenObjekt = class(TObject)
  GrundDaten : TArtGrundDaten;
end;

DatenObjektListe : TObjectList;  // nimmt spezif. Daten von TDatenObjekt auf

for i := 0 to DatenObjektListe.Count - 1 do
  ArtAusgObjekt := TArtAusgObjekt (AusgObjektListe.Items[i]);

Ist das Letzte ein Typecast ? :gruebel: Die Nomenklatur ist da etwas ungenau. 8-) Nenne man das Konstukt, wie man will. Mir ists egal, weil es einwandfrei funktioniert ohne Nachteile.

Am Beispiel sieht man jedenfalls, wie man starre Records und Klassen kombinieren kann. Die Klassen, die den Record enthalten, werden an anderen Stellen jedenfalls noch OOP-mässig erweitert.

[xZise]

Moin,

Zitat:

Zitat von Hansa (Beitrag 1053199)

Du bist mit der TList vermutlich wirklich etwas zu kurz gesprungen. 8-) Wie gesagt : TobjectList und OwnsObjects sollte auf true stehen.[...]

Aber nur dann auf true stelle, wenn danach die Elemente nicht mehr bestehen sollen. Und das ist doch bei ihm nicht der Fall: Also OwnObjects auf false, dann werden die Objekte nicht automatisch freigegeben. Ansonsten werden sie beim entfernen aus der Liste (z.B. mit Delete oder Clear) freigegeben. Also auch, wenn du die Liste freigibst. Du kannst OwnObjects jederzeit via property setzen und beim TObjectList.Create. Standardmäßig steht OwnObjects auf true.

Zitat:

Zitat von Hansa (Beitrag 1053199)

@Daniel : wäre gut, wenn man beim Schreiben sehen könnte, welche Delphi-Version eingesetzt wird. [...]

So ich habe mal ein Eintrag erstellt.

Übrigens wenn ich das richtig verstehe würde ich das so in der Art machen:

Delphi-Quellcode:

TMetaData = class(TObject)
  Name : string;
  [...]
end;

TFile = class(TObject)
  MetaData : TMetaData;
  Data : TStream; // Oder TMemoryStream
end;

Alternativ könnte man auch TFile von TMetaData erben lassen. Dürfte glaub ich besser sein.

MfG
Fabian

PS: Ich würde das letzte als Typecast ansehen. Weil was ist, wenn du irgendwas anderes reinkloppst. Deshalb würde ich entweder Generics verwenden (gibts leider nicht für D7) oder halt das Kapseln.

[Chemiker]

Hallo,

Zitat:

Leider gibt es viele Delphi-Programierer die den Schritt vom Record zur Klasse nicht vollziehen.

Wobei man sagen muss das beim neuen Delphi XE auch einige Neuerungen nicht von TObject kommen, sondern dafür auch Records eingesetzt wurden.

Bis bald Chemiker

[Hansa]

Zitat:

Zitat von xZise (Beitrag 1053207)

Moin,
Aber nur dann auf true stelle, wenn danach die Elemente noch bestehen sollen.

Nein, nein, dann muss es auf false stehen. OwnsObjects = true heisst : Beim Freigeben der Liste wird alles enthaltene aufgeräumt/entfernt. Du schreibst das ja selber im nächsten Satz. :mrgreen:

Zitat:

Zitat von xZise (Beitrag 1053207)

Übrigens wenn ich das richtig verstehe würde ich das so in der Art machen:
[delphi]TMetaData = class(TObject)
Name : string;
[...]
end;

Ne, so ist das nicht richtig. Dürfte zwar gehen, aber zumindest teilweise überflüssig. Ich muss da etwas weiter ausholen, weil es wichtig ist. Insbesondere auch für die, die mit OOP (notfalls Hint lesen) nicht recht was anzufangen wissen. Früher gab es Records. Das waren reine Daten. Üblich war und ist folgende Vorgehensweise (im Prinzip zumindest) : man liest aus einer Datenbank-Tabelle einen Datensatz (^= Record) in eine Variable und hat die Daten dann im Programm zur Verfügung. Ist doch schon mal gut, was ? :mrgreen:

Irgendwann kam dann mal irgendwer auf die Idee, dass die Datensätze sowieso gelesen, geschrieben oder sontwas werden müssen. Wieso sollte man eigentlich den Datensätzen nicht gleich sagen, was sie machen können ? Die reinen Daten, also Records hatten plötzlich die Möglichkeit auch "Methoden" zu haben. Das wären dann die heutigen TObject, TClass etc. Typen.

Zurück zur Ausgangsfrage : es geht um Dateiname, Dateigroesse usw., also um ungefähr das, was TSearchRec sowieso hat. Man beachte auch das "Rec" im Namen. In meinem Beispiel benutze ich auch einen Record. Allerdings innerhalb der TObjectList. Diese kriegt notfalls noch Methoden verpasst. Der Record ist starr und braucht keine Methoden. xZise verwendet in seinem Bsp. TObject, obwohl er dafür gar keine Methoden braucht. Da würde es auch ein Record tun. Gut, das dürfte vernachlässigbaren Speicher-Mehrbedarf/Laufzeit bedeuten, im Prinzip aber auch nur Peanuts. 100 Bytes, 1 Millisekunde mehr, was solls ? Allerdings : Record ist mehr oder weniger egal. Wenn das OwnsObjects der TObjectList auch einiges (besser gesagt : sehr viel) selber erledigt, die TObject-Dinger muss ich trozudem mit create erzeugen, was bei Records überflüssig ist.

[Chemiker]

Hallo Hansa,

die Records musst Du doch auch erstellen.

Bis bald Chemiker

[Hansa]

Inwiefern muss ich die wo erstellen ? :shock: Oder gibts jetzt sogar so was wie Rec1.Create () ? Ich sage doch auch nicht Int1.Create oder Real2.Free.

[implementation]

Delphi-Quellcode:

var
  rec: ^Recordtyp;
begin
  New(rec);
  ...
  rec^.Feld := ...;
  // evtl. geht auch: (zumindest beim FPC)
  rec.Feld := ...;
  ...
  Dispose(rec);
end;

Natürlich nur bei Zeigern nötig :wink:

[xZise]

Zitat:

Zitat von Hansa (Beitrag 1053227)

Zitat:

Zitat von xZise (Beitrag 1053207)

Moin,
Aber nur dann auf true stelle, wenn danach die Elemente noch bestehen sollen.

Nein, nein, dann muss es auf false stehen. OwnsObjects = true heisst : Beim Freigeben der Liste wird alles enthaltene aufgeräumt/entfernt. Du schreibst das ja selber im nächsten Satz. :mrgreen: [...]

Öhr ja mist ... du hast recht da fehlt irgendwo eine Verneinung.

Und warum habe ich das mit Klassen gemacht? Ich frage mich nämlich wie du neue Einträge in die ObjectList bekommen willst:

Delphi-Quellcode:

var
  datei : TArtGrundDaten;
  list : TObjectList;

list := TObjectList.Create();
datei.name := 'foobar';
list.add(datei);
datei.name := 'Hallo Welt';
list.add(datei);

Das heißt irgendwo muss du Datei reinitialisieren. Das macht man i.d.R. mithilfe von new oder einer Methode (also wie bei bei der Methode Rect()). Ersteres hat den Nachteil: TObjectList wird das Objekt vermutlich nicht freigeben (korrigiert mich, wenn das nicht stimmt). Bei zweiteren, hast du ja ausgeführt, dass das ja eigentlich eine Methode der Datei ist, dann kann man das auch gleich zum Objekt machen.

UND inzwischen geht ja auch das:

Delphi-Quellcode:

type
  TFoo = record
    x : integer;
    function getXsqr() : Integer;
  end;

Und dann hatte ich auch erwähnt, dass man TFile von TMetaData erben lassen kann. Das geht bei records nicht.

Delphi-Quellcode:

type
  TMetaData = class;
  TFile = class(TMetaData)
    Data : TStream;
  end;

MfG
Fabian

[samso]

Um das Typecasting komplett zu vermeiden, kann man generische Listen verwenden, aber die gibt es bei Delphi 7 nicht.
Ich benutze sowohl Records als auch Klassen. Die Entscheidung welches Konstrukt ich verwende, hängt vom Anwendungsfall ab. Dabei berücksichtige ich die Vorteile die die Strukturen jeweils bieten:
Vorteile Records:

• 4 Byte weniger Speicherbedarf pro Instanz
• Einzelne Instanzen können auf dem Stack angelegt werden (schneller)
• Automatisch angelegte Instanzen werden auch automatisch freigegeben

Vorteile Klassen:

• Vererbung möglich
• Typeinformation zur Laufzeit vorhanden

Wenn ich also sehr viele Instanzen anlegen möchte (Hausnummer: mehr als 10000) und keine Vererbung benötige, dann benutze ich gerne auch Records. Um eine Liste von Records zu verwalten, verwende ich meist ein offenes Array, weil ich mich dann nicht um die Freigabe zu kümmern brauche. Dafür habe ich einen höheren Aufwand beim Hinzufügen der Instanzen. Aber man kann natürlich auch TList benutzen.
Zurück zur Ausgangsfrage: Um das Typcasting einzuschränken, würde ich bei TMyFile die Get-Funktion ändern. Etwa so:

Delphi-Quellcode:

   
type TMyFiles = class 
  private
    FList: TList;
  public
  property Items[Index: Integer]: pFileRec read Get write Put; default;
end;

Das Typecasting ist dann nur einmal in "Get" bzw. "Put" notwendig. Der Zugriff sieht dann so aus:

Delphi-Quellcode:

var
  allFileList: TMyFiles;
...
if allFileList[i].ext='PAS' then

Der Klasse TMyFiles ist es jetzt egal, ob sie "Besitzer" der Records ist, oder ob sie nur Verweise auf die Records verwaltet. Beim Freigeben muss man natürlich unterscheiden, ober man nur die Verweise freigeben will, oder auch die Records. Das kann man dann so machen, wie TObjectlist (ein Boolean zeigt an, was freigeben werden soll) oder man kümmert sich in jedem Einzelfall selbst darum.
N.B. Die Add Funktion muss natürlich auch noch entsprechend geändert werden (statt TFileRec nun pFileRec), oder man erfindet eine neue Funktion AdRef(file: pFileRec) oder wie auch immer...

[alzaimar]

Wieso verwendet man nicht:

Delphi-Quellcode:

MyFileList : Array Of TFileinfoRecord;

Typensicher, kein TypeCasting, kein Create, kein Free.

[xZise]

Aber gerade das befüllen ist ziemlich langsam.

MfG
Fabian