Pointer-Eigenschaft einer Klasse: Zugriffsverletzung

[little-x]

Hallo,

angenommen ich haben 2 Klassen, die im Interface-Teil einer Unit direkt untereinander stehen:

Delphi-Quellcode:

Type  TFather = Class
    vorname:  string;
    alter:  integer;
end;

Type TChild = Class
    vorname:  string;
    alter:  integer;
    Vater:  Pointer;   // <- hier kommt das Problem; hier soll der Papa rein.
end;

Im weiteren Verlauf erzeuge ich jeweils ein Objekt (Vater zuerst), mit Create und belege die Werte. Dabei kommt an einer Stelle eine Fehlermeldung:

Delphi-Quellcode:

      VaterObject:= TFather.Create;
      VaterObject.vornamename:= 'Horst';
      VaterObject.alter:= 30;

      ChildObject= TChild.Create;
      VaterObject.vornamename:= 'Horstsohn';
      VaterObject.alter:= 3;
      ChildObject.Vater:= VaterObject;   // <- Hier kommt die Fehlermeldung die ich nicht verstehe!

Und zwar kommt an der gekennzeichneten Stelle eine Speicher-Zugriffsverletzung.
Um folgendes Zitat vorweg zu nehmen:

Zitat:

Warum nimmst Du nicht TFather anstatt Pointer?

Das hier ist nur ein Beispiel. Mein Programm ist sehr viel komplexer, ich möchte niemanden verwirren. Ich weiß halt nicht immer den Datentyp, sondern nur dass es immer eine "Datenstruktur" ist (also Objekte irgendwelcher Klassen). Später kann ich diese mit

Delphi-Quellcode:

TClassname(Child.Vater).blabla

dereferenzieren.
Wo es super funktioniert, ist beim TTreeItem. Hier gibt es die Eigenschaft Data:Pointer. Funktioniert einfandfrei:

Delphi-Quellcode:

tvitem.data:= xy;//beliebige Objektstruktur

Weiß jemand was ich hier falsch mache?

Grüße!

[Phoenix]

Delphi-Quellcode:

Child.Vater := @VaterObjekt;

Du willst ja schliesslich die Adresse des Objektes in den Pointer stecken.

[little-x]

Funktioniert auch nicht (gleiche Fehlermeldung).

Danke trotzdem

[little-x]

Was funktioniert ist:

Delphi-Quellcode:

var tmp_ptr: Pointer;

...
     tmp_ptr:= @VaterObject;

Hier kommt dann wierder der Fehler:

Delphi-Quellcode:

ChildObject.Vater:= tmp_ptr;

Kann es sein dass die Klasseneigenschaft irgendwie geschützt ist?
Sollte ich sie vielleicht als Public deklarieren?
Oder gibt es irgendwelche Sperren bzw. Restriktionen, bei denen nicht mehrere Objekte in unterschiedllichen Klassen sich gegenseitig aufrufen dürfen?

[sirius]

Bei D6 muss man bei Pointern IHMO noch etwas typecasten.
Versuch doch mal diese Sachen:

Delphi-Quellcode:

ChildObject.Vater:= pointer(VaterObject);
//bzw.
ChildObject.Vater:= pointer(@VaterObject);
//wobei das eigentlich egal sein sollte

[Phoenix]

Zitat:

Zitat von little-x

Kann es sein dass die Klasseneigenschaft irgendwie geschützt ist?
Sollte ich sie vielleicht als Public deklarieren?
Oder gibt es irgendwelche Sperren bzw. Restriktionen, bei denen nicht mehrere Objekte in unterschiedllichen Klassen sich gegenseitig aufrufen dürfen?

Uh. erm.. Du willst NIE von extern auf Felder der Klasse zugreifen. Was Du willst ist ein Property erstellen, welches den Zugriff auf das Feld kapselt.

Delphi-Quellcode:

  TChild = Class
    vorname:  string;
    alter:  integer;
    FVater:  Pointer;
  public
    property Vater: Pointer read FVater write FVater; // <-- fehlt
  end;

[Bbommel]

Eigentlich müsste es genauso funktionieren, wie du es gemacht hast - cih verwende in einem Projekt genau die gleiche Struktur und das klappt wunderbar (das mit dem @ kannst du imho auch vergessen, da Objekte eh nur als Pointer zugewiesen werden).

Daher die Frage: Hast du das Beispiel auch genau in der einfachen Form, wie du sie hier reingestellt hast, mal ausprobiert? Ich würde ja eher vermuten, dass der Fehler woanders liegt, da gerade beim Zuweisen einer Speicheradresse an einen Pointer nix passieren sollte. Ist das, was hier vom Typ TChild ist, richtig deklariert? Rufst du vom richtigen Objekt den constructor auf? Würde vermuten, dass eher in dem Bereich ein Fehler liegt, denn offenbar kann auf die Eigenschaft "fahther" nicht zugegriffen werden.

Das könnte vielleicht so passieren:

Delphi-Quellcode:

procedure irgendwas;

var vadder: TFahther;
    kind: TChild;

begin
  vadder:=TFahther.Create;
  // irgendwelche Werte an den Vater...

  kind:=TChild(Tfahther.Create);  // machst du in deinem komplexeren Projekt irgendwie sowas?
  kind.vater:=vadder;             // ...denn in dem Fall müsste genau dein Fehler kommen.
end;

Mal so als Idee. Allerdings gerade ungetestet.

Bis denn
Bommel

[teebee]

Dein Minmalbeispiel lässt sich bei mir anstandslos kompilieren (nach Änderung der Eigenschaft 'vornamename'...) und läuft auch ohne Fehlermeldung durch. Das Problem liegt also wahrscheinlich an etwas anderem.

[little-x]

Zitat:

Mal so als Idee. Allerdings gerade ungetestet.

@Bbommel: Nun ja, um ehrlich zu sein mache ich es eigentlich genauso. Du meinst, dass dann der Fehler kommen muss? Woran liegt das in dem Fall?

ansonsten, das mit der fehlenden Property klingt logisch, ich werd es ausprobieren.

Ich prüfe mal nochmal ob der Fehler nicht vielleicht doch woanders liegt. Bis hierher Danke an alle, aber lasst mal "kurz" locker... will nicht dass sich noch mehr andere den Kopf zerbrechen und dabei Äpfel mit Birnen vergleichenm, weil der Fehler bei mir liegt...

[Bbommel]

Zitat:

Zitat von little-x

Zitat:

Mal so als Idee. Allerdings gerade ungetestet.

@Bbommel: Nun ja, um ehrlich zu sein mache ich es eigentlich genauso. Du meinst, dass dann der Fehler kommen muss? Woran liegt das in dem Fall?

Naja, weil für die Speicherzuweisung (und ggf. auch für die Nutzung von Methoden, Stichwort: vrtuelle Methoden) wichtig ist, welchen Constructor du aufrufst. In deinem Fall ist es derjenige vom Objekt Vater, in dem es die Eigenschaft "vater" aber gar nicht gibt. Wenn du nun dieser Eigenschaft einen Wert zuweisen willst, dann geht das schief, weil für die Eigenschaft kein Speicher vorhanden ist.

Das merkst du in meinem Beispiel aber erst zur Laufzeit, weil du das Kind ja als TChild deklariert hast: Editor und Compiler werden sich also nicht über die fehlende Eigenschaft "vater" beschweren. Und wegen des Typecasts lassen sie dir auch durchgehen, dass du den falschen Constructor aufrufst.

Hm, hoffe, ich hab das 1. richtig und 2. verständlich erklärt. :)

Bis denn
Bommel