@self abhängig von Codeposition

[hackerknecht]

@self ist sicher keine unkritische Sache, da in der Regel die Arbeit mit SELF wohl ausreicht.
Haben wir 2 Klassen mit einer virtuellen

Delphi-Quellcode:

function Klasse.IAM : pointer;
begin
 result := @self;
end;

so macht es in der Kindklasse einen Unterschied ob die überschriebene IAM
eben obigen Code genauso ausführt, oder

Delphi-Quellcode:

function KindKlasse.IAM : pointer;
begin
/// result := @self;
 result := inherited IAM;
end;

verwendet wird.
Ist das ein Fehler ?? vom Compiler ?
Ich meine eine Membervariable, sollte doch immer den gleichen Wert liefern,
egal wo in der Hirachie diese verwendet wird.

[jim_raynor]

Self ist eine Variable die auf dem Stack abgelegt wird. Dementsprechend bekommst du Probleme, wenn du einen Pointer auf Self zurückgibts. Die Frage ist wozu du eine Funktion brauchst, die dir Self zurück liefert.

[Bernhard Geyer]

Wieso verwendest Du @self?

Wenn Du self und nicht @self verwendest sollte doch reichen oder was willst Du mit einem Pointer auf den Self-Pointer?

[Robert Marquardt]

Self ist wie bereits gesagt auf dem Stack abgelegt. Es ist einfach der erste Parameter einer Methode.
Eine class method hat als Self nicht den Zeiger auf die Instanz des Objekts sondern auf die Klasseninformationen sprich das Template fuer Instanzen.
Parameter fallen unter die lokalen Variablen, die nach Ende der Methode ungueltig werden.

[hackerknecht]

Vielen Dank für Euere schnelle Hilfe !
Wenn self nur auf dem Stack liegt, ist das Problem mit @self klar.
( Hatte gehofft/gedacht, daß self mit/bei den Member-variablen gespeichert wird )
(( Wozu ?? Ich erstelle mehrere Indices auf Bäume von polymorphen Objecten zum Sortieren/Suchen.
Bei einem Index "Name" z.B. muss das Object einen Pointer auf seinen Namen-Member liefern.
@Fname z.B. , kommt dann ein anderer Index z.B. PLZ dann halt @FPLZ ec..
Diese pointer werden dann an entsprechende Vergleichsfunktionen weitergeliefert.
Da einige Funktionen sehr abstrakt sind, arbeitet vieles nur mit Pointern.
Bei einem komplexen Index, der nicht über einen einfachen Vergleich wie String- oder
Integervergleich machbar ist, sondern nur über die Objecte, müssten dann die Objecte einen
Zeiger auf sich selbst liefern können ...))

[jim_raynor]

Also:

Wenn man eine Methode mit:

MyObj.MyMethode aufruft. Dann ist innerhalb von MyMethode Self einfach MyObj. Also musst du als Aufrufer der Methode Self kennen, da dies ja der Zeiger auf das eigentliche Objekt ist.

Da ich wirklich bei deinen ganzen Pointern nicht durchsehe, hoffe ich, dass dir das bissle hilft.

[barf00s]

Zitat von hackerknecht:

Vielen Dank für Euere schnelle Hilfe !
Wenn self nur auf dem Stack liegt, ist das Problem mit @self klar.
( Hatte gehofft/gedacht, daß self mit/bei den Member-variablen gespeichert wird )
(( Wozu ?? Ich erstelle mehrere Indices auf Bäume von polymorphen Objecten zum Sortieren/Suchen.
Bei einem Index "Name" z.B. muss das Object einen Pointer auf seinen Namen-Member liefern.
@Fname z.B. , kommt dann ein anderer Index z.B. PLZ dann halt @FPLZ ec..
Diese pointer werden dann an entsprechende Vergleichsfunktionen weitergeliefert.
Da einige Funktionen sehr abstrakt sind, arbeitet vieles nur mit Pointern.
Bei einem komplexen Index, der nicht über einen einfachen Vergleich wie String- oder
Integervergleich machbar ist, sondern nur über die Objecte, müssten dann die Objecte einen
Zeiger auf sich selbst liefern können ...))

hmm, objekte sind ja schon zeiger, wozu also dieses komplizierte self-pointer-abstrakt-blah-konstrukt

wenn du uns an deinem code (oder schnippsel davon) teilhaben lässt, wird sich vieles vllt erklären - oder vereinfachen - lassen