Hallo,

ich habe eine Klasse von TObject abgeleitet. Diese enthält 5 Extended Werte, einen constructor, einen destructor und 2 Methoden. In D3 hat diese Klasse eine InstanceSize von 56 Bytes in D7 aber 60!? Wie kommt es zu dieser Vergrößerung. Da ich die Objekte in einen Stream schreibe und aus diesem wieder lese, hab ich in D7 jetzt das Problem, dass ich den Stream, den ich mit D3 geschrieben habe nicht mehr korrekt lesen kann.

Ich habe mich darauf verlassen, dass die Eigenschaften der Objekte jeweils 4 Bytes nach dem Objektanfang beginnen, wie es auch dieser Code aus der Code-Lib tut.

Ouch. Hat sich ggf. die Größe eines der Elemente geändert? Schau mal in der RTTI nach, die müsste die Informationen dazu liefern.

Eine Lösung wäre, die alte Deserialisierung in D3 zu nehmen, die Werte in ein XML-Format (oder in Strings zeilenweise in textdateien oder...) zu packen und die Serialisierung dann in D7 zu nehmen und aus dem XML wieder in den usprünglichen Stream packen. Sind dann halt zwei neue Tools zum konvertieren, aber die Hälfte vom Code ist ja schon da, von daher kann man den Aufwand relativ gering halten.

naja, macht es überhaupt sinn das gesammte Object abzuspeichern? Wozu braucht man dann Constructor, Destructor etc. beim abspeichern. Wäre es nicht sinnvoller gewesen nur die Werte zu speichern die auch wirklich gespeichert werden müssen?

Das die Objecte sich zwischen den Delphiversionen unterscheiden sollte einem doch irgendwo klar sein. Spätestens bei 64Bit-Delphi kommt es dann zu Problemen...

Hallo Phoenix und SirThornberry,

ich speichere ähnlich wie im oben verlinktem Code die Eigenschaften des Objektes ab. Dazu nutze ich auch die Eigenschaft InstanceSize. Ich habe jetzt einfach einmal anstatt 4 Bytes bis zum Beginn der Eigenschaften 8 Bytes benutzt und es funktioniert. Grundlage des Programms von Chewie und auch meiner Speicherroutine war diese Borlandseite zur Speicherverwaltung. Diese galt für D5, und gilt offensichtlich nicht mehr für D7. Hat einer einen Link zur Speicherverwaltung unter D7?

Zitat von SirThornberry:

naja, macht es überhaupt sinn das gesammte Object abzuspeichern? Wozu braucht man dann Constructor, Destructor etc. beim abspeichern. Wäre es nicht sinnvoller gewesen nur die Werte zu speichern die auch wirklich gespeichert werden müssen?

Wird doch gemacht.
Die Methoden auf dem Objekt liegen sowieso nie im Objekt selber, sondern nur einmal im kompletten Programm. Die RTTI weiss wo die Methode liegt, im Objekt selber liegt - wenn überhaupt, das weiss ich leider nicht zu 100% - ein Pointer auf den ausführbaren Codebereich.

Deswegen muss bei Methoden ja auch immer ein Pointer auf den Datenbereich der aufrufenden Instanz als erster (versteckter) Parameter an den Codebereich übergeben werden, damit man überhaupt auf den Properties des richtigen Objektes arbeitet.

Das hat auch den manchmal unangenehmen Nebeneffekt, das man Methoden auf Objekten aufrufen kann, die schon freigegeben sind. - Wenn diese Methoden nicht auf Properties des Objektes zugreifen sondern z.B. reine Berechnungen auf den Parametern machen, dann funktioniert das sogar. Nur wenn ein Property geändert werden soll, dann kommt es zu einer Speicherschutzverletzung, weil der Speicher für das Objekt ja schon bei der Freigabe an das OS zurückgegeben wurde.

Zitat von MrSpock:

ich speichere ähnlich wie im oben verlinktem Code die Eigenschaften des Objektes ab.

Mein Vorschlag wäre TReader und TWriter zu benutzen.

zusammenfalten · markieren

Delphi-Quellcode:

type
  TMyObject = class(TObject)
  private
    FValueA: Integer;
    FValueB: String;
  public
    procedure SaveToStream(AStream: TStream);
    procedure LoadFromStream(AStream: TStream);
    property ValueA: Integer read FValueA write FValueA;
    property ValueB: String read FValueB write FValueB;
  end;

zusammenfalten · markieren

Delphi-Quellcode:

procedure TMyObject.LoadFromStream(AStream: TStream);
begin
  with TReader.Create(AStream, 4096) do
    try
      FValueA := ReadInteger;
      FValueB := ReadString;
    finally
      Free;
    end;
end;

procedure TMyObject.SaveToStream(AStream: TStream);
begin
  with TWriter.Create(AStream, 4096) do
    try
      WriteInteger(FValueA);
      WriteString(FValueB);
    finally
      Free;
    end;
end;

Ist deine Klasse von TComponent abgeleitet, kannst du auch WriteComponent und ReadComponent benutzen.

Hallo Sprint,

ich wollte mir die Arbeit sparen, jedes Element einzeln speichern zu müssen. War es früher nicht einmal so, dass bereits TPersistent Lade und Speichermöglichkeiten für die Eigenschaften angeboten hat?

Zitat von MrSpock:

ich wollte mir die Arbeit sparen, jedes Element einzeln speichern zu müssen.

Vielleicht wärst du jetzt schon fertig.

Zitat:

War es früher nicht einmal so, dass bereits TPersistent Lade und Speichermöglichkeiten für die Eigenschaften angeboten hat?

DefineProperties