Kopie eines Klassenobjekts erstellen

[DieDolly]

Zitat:

Wenn man eine eigenes Objekt kopierbar habe will implemtiert man die Methoden Assign und AssignTo selbst.
Wenn man ein Objekt von TPersistent ableitet muss man Methoden zum Speichern(als stream/Datei) und Lesen(von Stream/Datei) des Objekts implemtieren.

Die Daten lade und speichere ich eh selber mit extra Quelltext. Was anderes käme mir gar nicht in den Sinn.

Ist von TPersistent ableiten also gut genug und genau so perfomant wie TObject? Es geht hier um das Erstellen von circa 150 bis 200 Klassenobjekten bei Programmstart.
So wie ich das sehe leitet TPersistent am Ende auch wieder nur von TObject ab und fügt 7 neue Prozeduren und Funktionen ein.

Komplizierte Objekttypen habe ich nicht. Strings, Integer und eindimensionale Arrays (String, Integer und einfache Enums).

[Stevie]

Wenn die Klassen, die kopiert werden sollen, so umfangreich und zahlreich werden, kann man auch Code generieren - entweder durch Tools wie DelphiAST, oder man packt die Klassen in ein Projekt, in denen das anhand deren RTTI passiert. Dann hat man die Vorteile von beiden Herangehensweisen.

[DieDolly]

Verstanden was du da gerade geschrieben hast, habe ich leider nicht

Stellen 100 Properties denn ein Problem dar?

Speicherverbrauch meiner Anwendung mit und ohne Klassenobjekten im Detail
mit 0 Klassenobjekten bei Programmstart 9,2 MB
mit 70 Klassenobjekten 10,7 MB.

[Stevie]

Meine Aussage bezog sich auf den Post von QuickAndDirty zuvor

[Andreas L.]

Ich mach es z. B. so:

Delphi-Quellcode:

  TtoTreeNodeAttribute = class(TtoCollectionItem)
  private
    FData: TtoData;
    FName: String;
    ...
  protected
    procedure SetName(Value: String);
    procedure SetData(Value: TtoData);
    ...
  public
    ...
    procedure AssignTo(Dest: TPersistent); override;
  published
    property Name: String read FName write SetName;
    property Data: TtoData read FData write SetData;
    ...
  end;

...

procedure TtoTreeNodeAttribute.AssignTo(Dest: TPersistent);
var
  DestObj: TtoTreeNodeAttribute;
begin
  inherited AssignTo(Dest); 
  if Dest is TtoTreeNodeAttribute then
  begin
    DestObj := TtoTreeNodeAttribute(Dest);
    DestObj.BeginUpdate;
    try
      DestObj.FData.Assign(FData);
      DestObj.FName := FName;
      ...
    finally
      DestObj.EndUpdate;
    end;
  end;
end;

procedure TtoTreeNodeAttribute.SetName(Value: String);
begin
  if (FName <> Value) and (Value <> '') then
    FName := Value;
end;

procedure TtoTreeNodeAttribute.SetData(Value: TtoData);
begin
  FData.Assign(Value);
end;

...

Anmerkung: Die Methoden BeginUpdate() und EndUpdate() habe ich selbst implementiert weil es sie in in TPersistent nicht gibt. (Delphi 2009)

[DieDolly]

Delphi-Quellcode:

DestObj.FData.Assign(FData);
DestObj.FName := FName;

Bei ein paar Properties kein Problem. Bei alles über 50 aufwendig und doppelter Aufwand, wenn irgendwas geändert werden muss. Mal von der Gefahr abgesehen, wenn man vergisst AssignTo ebenfalls zu erweitern wenn man die Klasse erweitert.

[peterbelow]

Zitat von DieDolly:

Zitat:

Wenn man eine eigenes Objekt kopierbar habe will implemtiert man die Methoden Assign und AssignTo selbst.
Wenn man ein Objekt von TPersistent ableitet muss man Methoden zum Speichern(als stream/Datei) und Lesen(von Stream/Datei) des Objekts implemtieren.

Die Daten lade und speichere ich eh selber mit extra Quelltext. Was anderes käme mir gar nicht in den Sinn.

Ist von TPersistent ableiten also gut genug und genau so perfomant wie TObject? Es geht hier um das Erstellen von circa 150 bis 200 Klassenobjekten bei Programmstart.
So wie ich das sehe leitet TPersistent am Ende auch wieder nur von TObject ab und fügt 7 neue Prozeduren und Funktionen ein.

Komplizierte Objekttypen habe ich nicht. Strings, Integer und eindimensionale Arrays (String, Integer und einfache Enums).

Egal von was Du ableitest, den Code für das Kopieren der Daten mußt Du auf jeden Fall schreiben. Assign/AssignTo in TPersistent sind nur Platzhalter, die eine Exception auslösen, wenn Du nicht mindestens AssignTo überschreibst. Es hängt also von Dir ab, wie performant das Ganze ist . TPersistent enthält einiges an Kode für die Unterstützung des VCL Streamingmechanismusses, aber das belasted Abkömmlinge nicht wesentlich. Trotzdem würde ich persönlich nicht von einer Klasse ableiten, deren Funktionalität Du nicht wirklich brauchst. Ein Argument für TPersistent wäre allerdings, wenn Du z. B. Assign und AssignTo so implementieren willst, dass der Inhalt eines deiner Objekte auch z. B. per Assign in eine TStringlist oder TMemo.Lines oder so kopiert werden können soll.

[DieDolly]

Zitat:

Egal von was Du ableitest, den Code für das Kopieren der Daten mußt Du auf jeden Fall schreiben. Assign/AssignTo in TPersistent sind nur Platzhalter, die eine Exception auslösen, wenn Du nicht mindestens AssignTo überschreibst.

Komisch. Ich leite gerade von TPersistent ab, Mache LokalObject.Assign(PublicObject); und alles funktioniert ohne exception.

Zitat:

Ein Argument für TPersistent wäre allerdings, wenn Du z. B. Assign und AssignTo so implementieren willst, dass der Inhalt eines deiner Objekte auch z. B. per Assign in eine TStringlist oder TMemo.Lines oder so kopiert werden können soll.

Brauche ich zum jetzigen Zeitpunkt nicht. Zum jetzigen Zeitpunkt kopiere ich nur komplette Klassenobjekte.

Sonst, wenn das besser ist, nehme ich Tigüs Idee ( https://delphihaven.wordpress.com/20...ng-using-rtti/ ).
Das mit Json lasse ich wegen dem Argument, dass Embarcadero das ja oft kaputt macht.,

Zitat:

Trotzdem würde ich persönlich nicht von einer Klasse ableiten, deren Funktionalität Du nicht wirklich brauchst.

Hat das einen Nachteil? Außer, dass ich Funktionen in der Autovervollständigung habe, die ich vielleicht nicht brauche?

[TiGü]

Zitat von DieDolly:

Zitat:

Trotzdem würde ich persönlich nicht von einer Klasse ableiten, deren Funktionalität Du nicht wirklich brauchst.

Hat das einen Nachteil? Außer, dass ich Funktionen in der Autovervollständigung habe, die ich vielleicht nicht brauche?

Objekte werden größer (SizeOf()).

[DieDolly]

Laut Windows Process Explorer, direkt nach Programmstart wenn alles geladen wurde:
TObject, private bytes 19.704 K, working set 31,644 K
TPersistent, private bytes 19.648 K, working set 31.536 K

Es gibt sicherlich einen anderen Unterschied irgendwo aber der scheint bei mir noch so klein zu sein, dass man ihn nicht merkt.
Die paar Byte sind heute eh egal und auf die kommts auch nicht an bei einer Speicherreservierung von rund 30 MB.

Ich habe das jetzt auch mal was genauer gemacht. Ob das richtig ist, weiß ich aber nicht.
Ich bin alle Objekte durchgegangen, habe deren Größe mit InstanceSize bestimmt, addiert und am Ende ausgegeben.
Für TPersistent bekomme ich 22680, für TObject auch 22680.

Es geht mir keineswegs darum ein paar bytes zu sparen. Ich frage mich nur, warum man TObject mit eigenem Assign, was vielleicht sogar noch anfällig ist, nehmen sollte, obwohl TPersistent doch schon alles liefert.