Warum geht das eigentlich nicht?

[Mavarik]

Hi!

Delphi-Quellcode:

type
  TFoo = class
    private
       FIMG : TImage;
    Property TheBitmap : TBitmap read FImg.Bitmap; // ???
  end;

Mavarik

[Dejan Vu]

Weil der backing store ein privates Feld sein muss und nicht die Property eines privaten Feldes. Vermutlich, vielleicht, keine Ahnung wird bei einem backing store direkt die Adresse im Getter/Setter einkompiliert. Stevie und andere Spezialisten können darüber bestimmt mehr sagen.

[DeddyH]

Anderseits ist es ja auch kein großer Aufwand, einen einzeiligen Getter zu schreiben.

[himitsu]

Die Frage ist eher: Was macht eine visuelle TImage versteckt in einer Komponente?
Oder wird die auch irgendwo angezeigt?

> TPicture oder TGraphit (wenn man den Typ kennt)

[Dejan Vu]

Zitat:

Zitat von DeddyH (Beitrag 1266037)

Anderseits ist es ja auch kein großer Aufwand, einen einzeiligen Getter zu schreiben.

Ich glaube, ihm geht es einfach um das 'warum'.

[DeddyH]

Da kann ich auch nur raten.

[Sir Rufo]

Ich vermute das dort impliziert eine Methode einkompiliert wird.

GetPropInfo liefert einen Zeiger für die Getter-/Setter-Methode auch wenn es sich um so eine simple Eigenschaftsdeklaration handelt.

Ist aber eben nur eine Vermutung meinereinerseits ...

Laut Wikipedia soll das wohl auch so sein.

Könnte man also einfach ausprobieren, ob

Delphi-Quellcode:

TFoo = class
private
  FBar : integer;
public
  property Bar : integer read FBar write FBar;
end;

den gleichen Code erzeugt wie

Delphi-Quellcode:

TFoo = class
private
  FBar : integer;
  procedure SetBar( const Value : integer );
  function GetBar : integer;
public
  property Bar : integer read FBar write FBar;
end;

procedure TFoo.SetBar( const Value : integer );
begin
  FBar := Value;
end;

function TFoo.GetBar : integer;
begin
  Result := FBar;
end;

[himitsu]

Nein, Delphi erzeugt da keine implizite Methoden.

In der RTTI ist in diesem Integer codiert, ob es sich um einen Zeiger (Offset) auf ein Feld handelt oder um eine Referenz auf eine Methode (Getter/Setter).


Es ist vielmehr so, daß der Delphi-Compiler ohne Getter/Setter intern oftmals den Code so erzeigt, als wenn man direkt auf das Feld zugreift. (zumindest im Windows ... k.A. wie das beim neuen Compiler aussieht)

[Uwe Raabe]

Zitat:

Zitat von Dejan Vu (Beitrag 1266035)

Weil der backing store ein privates Feld sein muss und nicht die Property eines privaten Feldes.

Interessanterweise geht sowas aber mit einem Record, wenn man beim read wieder ein Feld des Records anspricht. Und mit privat oder nicht hat das auch nichts zu tun.

Offenbar möchte der Compiler das direkt auslösen können. Das ist bei einer Klasseninstanz, die ja erst zur Laufzeit erzeugt wird, aber nicht möglich.

[himitsu]

Die RTTI nutzt, wie erwähnt, einen Offset.
Im compilierten Code wäre es praktisch kein Problem, aber es wird auch alles nochmal in der RTTI hinterlegt.

Bei einem Record ist immer alles direkt in dem Record und kann somit auch direkt angesprochen werden.
Bei einer Klasse werden praktisch zwei Adressen verschachtelt, was eben nicht "direkt" geht, vorallem da es auch noch eine Mischung aus direktem Feldzugriff und Getter/Setter sein kann.

[Dejan Vu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1266078)

Interessanterweise geht sowas aber mit einem Record, wenn man beim read wieder ein Feld des Records anspricht. Und mit privat oder nicht hat das auch nichts zu tun.

Delphi-Quellcode:

..
public
  fFoo : Integer;
  Property Foo : Integer read fFoo;
end;

ist zwar syntaktisch korrekt aber behämmert. Die Variante

Delphi-Quellcode:

..
protected
  fFoo : Integer;
public
  Property Foo : Integer read fFoo;
end;

ist Kretinismus 2.Klasse und ein Design Flaw übelster Sorte. Insofern 'muss' es sich um ein privates Feld handeln. Allerdings ist die Erwähnung von 'private' meinerseits ein Automatismus und rein syntaktisch ist das nicht notwendig.

Bei deinem interessanten Beispiel bei einem Record meinst Du das hier?

Delphi-Quellcode:

Type
  TRec1 = Record
    Foo : Integer;
  End;
  TRec = Record
    Rec1 : TRec1;
    Property Foo : Integer Read Rec1.Foo;
  End;

Das geht mit einer Klasse nicht, weil der Getter direkt auf eine Adresse gemappt werden muss. Das sieht man an der Fehlermeldung des Compilers bei

Delphi-Quellcode:

Type
  TRec1 = class
    Foo : Integer;
  End;
  TRec = class
    Rec1 : TRec1;
    Property Foo : Integer Read Rec1.Foo;
  End;

Zitat:

Zitat von Compiler

[Pascal Fehler] Unit16.pas(28): E2467 Record oder Objekttyp erforderlich

Ein Record geht also auch (=direktes Mapping)

[Stevie]

Das wäre übrigens eine der Spracherweiterungen, die ich mir für Delphi wünschen würde.

Natürlich kann man sich heute schon einen Getter schreiben, aber die Frage ist doch: warum kann der Compiler das denn bitteschön nicht für mich machen?

[JamesTKirk]

Zitat:

Zitat von Uwe Raabe (Beitrag 1266078)

Zitat:

Zitat von Dejan Vu (Beitrag 1266035)

Weil der backing store ein privates Feld sein muss und nicht die Property eines privaten Feldes.

Interessanterweise geht sowas aber mit einem Record, wenn man beim read wieder ein Feld des Records anspricht. Und mit privat oder nicht hat das auch nichts zu tun.

Offenbar möchte der Compiler das direkt auslösen können. Das ist bei einer Klasseninstanz, die ja erst zur Laufzeit erzeugt wird, aber nicht möglich.

Der Unterschied zwischen der Verwendung eines

Delphi-Quellcode:

record

(oder auch eines

Delphi-Quellcode:

object

) zu einer Klasseninstanz ist, dass bei ersterem das komplette Record Teil des für die Klasse alloziierten Feldbereichs ist. Bei letzterem ist nur der Zeiger auf die Klasseninstanz Teil des Feldbereichs. Das sieht man auch sehr schön, wenn man

Delphi-Quellcode:

TObject.InstanceSize

verwendet:

Delphi-Quellcode:

program tinstancesize;

{$apptype console}
{$ifdef fpc}
  {$mode objfpc}
{$endif}

type
  TTestRec = record
    Foo: LongInt;
    Bar: Int64;
    Blubb: Boolean;
  end;

  TTestClass1 = class
    Rec: TTestRec;
  end;

  TTestClass2 = class
    Obj: TObject;
  end;

begin
  Writeln(TTestClass1.ClassName, ': ', TTestClass1.InstanceSize);
  Writeln(TTestClass2.ClassName, ': ', TTestClass2.InstanceSize);
end.

Ausgabe:

Code:

TTestClass1: 32
TTestClass2: 8

Der Compiler kann nun also das Felder im Record direkt über einen Offset addressieren, während er bei einer Klasseninstanz eine Methode generieren müsste, um den Zugriff über die RTTI nicht allzu kompliziert zu gestalten, da man das ja beliebig tief schachteln kann:

Delphi-Quellcode:

program trecprop;

{$apptype console}
{$ifdef fpc}
  {$mode objfpc}
{$endif}

type
  TTestRec1 = record
    Foo: LongInt;
  end;

  TTestRec2 = record
    Bar: TTestRec1;
  end;

  TTestClass = class
    Rec: TTestRec2;
    property Foo: LongInt read Rec.Bar.Foo;
  end;

begin

end.

Zitat:

Zitat von Stevie (Beitrag 1266086)

Natürlich kann man sich heute schon einen Getter schreiben, aber die Frage ist doch: warum kann der Compiler das denn bitteschön nicht für mich machen?

Der Compiler könnte das durchaus machen, doch beim Zugriff auf einen Klassenzeiger ergibt sich ein Problem, dass sich bei einem Record nicht gibt: was, wenn der Klassenzeiger

Delphi-Quellcode:

Nil

ist? Ich mein, klar, der Compiler könnte entweder die Access Violation einfach durchlassen oder aber einen speziellen Exceptiontyp auslösen, aber wann rechnet man als Verwender der Klasse mit sowas? Der Sinn von Properties ist, dass man als Entwickler der Klasse sehr leicht die Implementierung der Property ändern kann (zum Beispiel von nem Feld zu nem Getter) ohne, dass es der Verwender großartig bemerkt (natürlich generiert der Compiler dann anderen Code, aber der Quelltext ändert sich nicht). Bei solchen automatisch generierten Gettern käme dann auf einmal ein neuer Exceptiontyp hinzu, mit dem man nicht unbedingt rechnet, vielleicht nicht nur als Benutzer nicht, sondern auch als Entwickler nicht.

Noch eine weitere Anmerkung zum Schluss: wer vor dem Performanceoverhead durch den Getter "Angst" hat, der soll doch einfach Inline verwenden:

Delphi-Quellcode:

program tinlinegetter;

{$ifdef fpc}
  {$mode objfpc}
{$endif}

type
  TTestClass1 = class
    Foo: LongInt;
  end;

  TTestClass2 = class
    Bar: TTestClass1;
    function GetFoo: LongInt; inline;
    property Foo: LongInt read GetFoo;
  end;

function TTestClass2.GetFoo: LongInt;
begin
  Result := Bar.Foo;
end;

var
  t: TTestClass1;
  i: LongInt;
begin
  i := t.Foo;
end.

(Hinweis: Kompilat nicht ausführen, da

Delphi-Quellcode:

t

und

Delphi-Quellcode:

Bar

nicht initialisiert sind!)

Zumindest FPC optimiert hier durch das

Delphi-Quellcode:

inline

den gesamten Call weg:

Code:

.section .text
        .balign 16,0x90
.globl  PASCALMAIN
        .type   PASCALMAIN,@function
PASCALMAIN:
.globl  main
        .type   main,@function
main:
.Lc6:
# Temps allocated between ebp+0 and ebp+0
# [26] begin
        pushl   %ebp
.Lc8:
.Lc9:
        movl    %esp,%ebp
.Lc10:
        call    FPC_INITIALIZEUNITS
# [27] i := t.Foo;
        movl    U_P$TINLINEGETTER_T,%eax
        movl    4(%eax),%eax
        movl    4(%eax),%eax
        movl    %eax,U_P$TINLINEGETTER_I
# [28] end.
        call    FPC_DO_EXIT
        leave
        ret
.Lc7:
.Le1:
        .size   main, .Le1 - main

Im Vergleich dazu der generierte Code ohne

Delphi-Quellcode:

inline

Code:

.section .text
        .balign 16,0x90
.globl  PASCALMAIN
        .type   PASCALMAIN,@function
PASCALMAIN:
.globl  main
        .type   main,@function
main:
.Lc6:
# Temps allocated between ebp+0 and ebp+0
# [26] begin
        pushl   %ebp
.Lc8:
.Lc9:
        movl    %esp,%ebp
.Lc10:
        call    FPC_INITIALIZEUNITS
# [27] i := t.Foo;
        movl    U_P$TINLINEGETTER_T,%eax
        call    P$TINLINEGETTER_TTESTCLASS2_$__GETFOO$$LONGINT
        movl    %eax,U_P$TINLINEGETTER_I
# [28] end.
        call    FPC_DO_EXIT
        leave
        ret
.Lc7:
.Le1:
        .size   main, .Le1 - main

Gruß,
Sven

[Stevie]

Zitat:

Zitat von JamesTKirk (Beitrag 1266088)

Der Compiler könnte das durchaus machen, doch beim Zugriff auf einen Klassenzeiger ergibt sich ein Problem, dass sich bei einem Record nicht gibt: was, wenn der Klassenzeiger

Delphi-Quellcode:

Nil

ist? Ich mein, klar, der Compiler könnte entweder die Access Violation einfach durchlassen oder aber einen speziellen Exceptiontyp auslösen, aber wann rechnet man als Verwender der Klasse mit sowas? Der Sinn von Properties ist, dass man als Entwickler der Klasse sehr leicht die Implementierung der Property ändern kann (zum Beispiel von nem Feld zu nem Getter) ohne, dass es der Verwender großartig bemerkt (natürlich generiert der Compiler dann anderen Code, aber der Quelltext ändert sich nicht). Bei solchen automatisch generierten Gettern käme dann auf einmal ein neuer Exceptiontyp hinzu, mit dem man nicht unbedingt rechnet, vielleicht nicht nur als Benutzer nicht, sondern auch als Entwickler nicht.

Und wo ist dann der Unterschied zu dem 0815 Getter, den wahrscheinlich die meisten an solch einer Stelle schreiben würden? (so wie du in dem untersten Beispiel) Wenn ich nen nilsafen Getter haben will, dann kann ich ihn immernoch selbst schreiben, aber für die Fälle wo ich bloß eine Property oder eine Funktion eines aggregierten Objekts nach außen leiten möchte könnt ich mir ein halbes Duzend Zeilen Boilerplate Code sparen.