Record als Konstantenobjekt nach Update D2009->Delphi XE

[himitsu]

Sobald lesend auf ein Property zugegriffen wird (also nicht Property := ...), wird READ verwendet, welches eine lokale Kopie des Wertes erstellt.
Alles was in dieser Kopie verändert wird, hat keinen Einfluß auf das Property.
[add] (bei direkten Zugriffen auf Felder ht es doch Einfluß, was aber so nicht erlaubt ist)

Darum wirft man hier nun auch endlich mal einen Compiler-Fehler.


Was aber leider auf Record-Methoden noch nicht zutrifft, da man diese nicht als "Konstant" deklarieren kann.
Ist schon witzig, wie man darüben dennoch eine Konstante verändern kann.

Dieser Code

Delphi-Quellcode:

with t.Item do
begin
  s := ':(';
  writeln(s); // str
  b := true;
  writeln(b); // true
end;
writeln(t.Item.s); // str <-- data loss
writeln(t.Item.b); // false <-- data loss
t.Item.s := ':)';
writeln(t.Item.s); // str <-- data loss

macht nun Folgendes:

Delphi-Quellcode:

Temp1 := t.Item;  // t.Item {Getter}
begin
  Temp1.s := ':(';
  writeln(Temp1.s);
  Temp1.b := true;
  writeln(Temp1.b);
end;
Temp2 := t.Item;
writeln(Temp2.s);
Temp3 := t.Item;
writeln(Temp3.b);
Temp4 := t.Item;
Temp4.s := ':)';
Temp5 := t.Item;
writeln(Temp5.s);

(die Codeoptimierung ist natürlich so schlau möglichst nur eine Temp-Variable zu nutzen und diese überall wiederzuverwenden, was aber an den auszuführenden Befehlen nichts ändert)



Da Emba ja leider nicht von selber auf die Idee kommt, hier nachher die TempVar an den Setter zurück zu übergeben, muß man es manuell machen.

Delphi-Quellcode:

MyVar := t.Item;  {Getter}
with MyVar do
begin
  s := ':(';
  writeln(s);
  b := true;
  writeln(b);
end;
t.Item := MyVar;  {Setter}

writeln(t.Item.s);  {Getter}
writeln(t.Item.b);  {Getter}

MyVar := t.Item;  {Getter}
MyVar.s := ':)';
t.Item := MyVar;  {Setter}

writeln(t.Item.s);  {Getter}

PS: Das trifft auch auf Objekte zu, genauer auf den Objektzeiger.
Den Objektinhalt kann man natürlich ändern, da er ja nicht in dieser Kopie enthalten ist.

PSS: Das selbe Problem hat übrigens auch die generische TList.
(vielleicht lade ich dazu ja irgendwannl meinen "Bugfix" hoch)

[SirThornberry]

Zitat:

Sobald lesend auf ein Property zugegriffen wird (also nicht Property := ...), wird READ verwendet, welches eine lokale Kopie des Wertes erstellt.

Das stimmt so nicht. Vielmehr dient read/write nur der Zugriffskontrolle zur Compilezeit. Beim ShowMessage wird hier intern (asm-code) keine Kopie von fMyRecord erstellt.

Delphi-Quellcode:

TMyClass=class(TObject)
private
  fMyRecord: TMyRecord;
public
  property MyRecord: TMyRecord read fMyRecord;
end;
[...]
ShowMessage(MyClassInstance.MyRecord.Value);

Der Code beim ShowMessage ist identisch mit:

Delphi-Quellcode:

TMyClass=class(TObject)
public
  MyRecord: TMyRecord;
end;
[...]
ShowMessage(MyClassInstance.MyRecord.Value);

Wäre ja schlimm der Zugriff auf eine Variable Länger dauert nur weil man den Scope oder dergleichen einschränkt.

[himitsu]

hmmmmm.

OK, wenn, dann aber nur, wenn direkt auf auf ein Feld zugegriffen wird.
Gut, so könnte es doch mal zufällig funktioniert haben. ( Codeoptimierung? )

Da aber theoretisch auch ein Getter möglich wäre, würde/dürfte es dennoch nicht gehn.
PS: Das ist/war natürlich auch ein "Sicherheitsloch", da es ja als "schreibgeschützt" deklariert war.

[SirThornberry]

Natürlich funktioniert das nur wenn auf ein Feld zugegriffen wird. Aber genau darum ging es hier.
Wenn man eine Funktion hat die etwas zurück liefert sollte klar sein das mit Änderung des Funktionsergebnisses nicht das geändert wird woraus das Funktionsergebnis zusammengesetzt wird. Dafür würde ja auch die Verknüpfung fehlen:

Delphi-Quellcode:

TMyObject = class(TObject)
private
  fVal1: Integer;
  fVal2: Integer;
  function GetValues(): TMyRecord;
public
  property MyRecord: TMyRecord read GetValues;
end;
[...]
function TMyObject.GetValues(): TMyRecord;
begin
  result.Val1:=fVal1;
  result.Val2:=fVal2;
end;

Hier sollte klar sein das folgendes nicht geht da die Verknüpfung von TMyREcord.Val mit fVal1 fehlt.
MyObjectInstance.MyRecord.Val1:=Irgendwas;

Zitat:

Gut, so könnte es doch mal zufällig funktioniert haben.

Nichts mit Zufall. Logik. Es macht überhaupt keinen Sinn eine Kopie zu erstellen da zur Compilezeit der erlaubte Zugriff fest steht.
Read und Write sind Schlüsselwörter um den Zugriff zu begrenzen ebenso wie private,protected etc.
[Edit]
Diese Schlüsselwörter dienen nicht dazu den Speicher zu verschlüsseln oder andere Stolpersteine zu erzeugen um zu verhindern das man den Speicher nutzen kann. Sie dienen einzig und allein dem Begrenzen des "normalen" Zugriffs über Properties etc.

[himitsu]

"zufällig" im sinne von, daß hier zufällig kein Getter verwendet wurde.

Wäre ja großer Zufall, wenn hier damals wirklich so geplant wurde, daß diese Codeoptimierung ausgenutzt werden konnte.

[SirThornberry]

Von mir aus darf das auch gern weiterhin so bleiben. So kommt man wenigstens auch (schreibend) an Variablen ran die beim Design der VCL-Klassen im Private-Teil gelandet sind aber besser im Protected-Teil aufgehoben wären.

[himitsu]

Sagen wir es mal so ... man kommt immernoch an solche Variablen ran, denn diesen Zugriffsschutz kann man umgehen (zum Glück kennt Delphi das @),

dann gibt es noch die neue RTTI, welche solch Privaten auch mit auflistet

und man kann sich auch auf andere Wege durch brutalstes Rumgepointere an die geheimsten Dinge ranschleichen.