Der this Zeiger - Wann?

Hallo!

Grundsätzlich ist mir der sinn des this Zeiger klar. Jedoch hat mich letztens etwas doch nachdenklich gemacht. ich schildere mal. Ich erstelle von einer BasisForm mehrfach-instanzen zur Laufzeit. Auf der BasisForm habe ich zur designtime ein paar standard komponenten (timer etc.) sowie 3rd party komponenten drauf getan. Sowohl visuelle und nicht visuelle (indy ftp z.b.). Desweiteren habe ich in der klasse der basis form noch ein paar elementvariablen als public/private sowie ein paar methoden So, jetzt meine frage:

(alles spielt sich direkt in der instanz der basis form ab. events etc.)
Wann muss man in diesem fall nun den this zeiger anwenden und wann nicht? grundsätzlich dachte ich für die elementvariablen: nein. für die form selber: ja. Weil z.B. BasisForm->Caption würde dann ja nicht die caption der instanz, sondern der BasisForm selber ändern, richtig oder? also muss für die form (instanz davon) selber immer mit this->Caption gearbeitet werden, klar soweit. bei den elementvariablen muss es ja nicht sein da es ja keine dereferenzierengs möglichkeit gibt. z.b. isTraffic würde ja immer nur im gleichen objekt bzw. in der instanz, die es betrifft sein. sonst müsste ich ja mit dem verweisoperator BasisForm->isTraffic arbeiten, wenn ich nicht die instanz meine, sondern nur die BasisForm ansich. soweit auch klar. Jetzt aber das problem:

Mir ist aufgefallen das die 3rd party komponenten sowie die indy ftp komponente ohne probleme ohne den zugriff mit dem this zeiger, in der entsprechenden instanz arbeiten. ABER ein TTimer muss anscheinend tatsächlich mit dem this zeiger angesprochen werden. Jetzt frage ich mich, wieso? Alle komponenten auf der BasisForm werden ja von der klasse verwaltet, auch TTimer, wie indy und alle anderen. Jedesmal wenn ich dann eine neue instanz erzeuge werden ja alle komponenten sowie elementvariablen mit erzeugt. Nur ist mir eben aufgefallen das ich auf den Timer ohne this zeiger dann anscheinend auf den normalen Timer der form (also nicht der, der instanz) zugreife. Indy und die anderen 3rd party komponenten kann ich ohne den this zeiger ansprechen. Schnall ich nun echt nicht.

eine möglichkeit die mir grad einfiel:
Kommt es drauf an in welchem event auf etwas zugegriffen wird? Wenn z.B. ein event das die form selber betrifft, wie z.B. OnShow, dann mit this zeiger. Wenn ein event das von TMainMenu Item ausgelöst wurde, dann ohne this zeiger möglich. kann das sein? Wäre irgendwie logisch.

akari

Hallo

verstehe nicht wo dein Problem liegt. Wenn ein Control oder Variable (und Controls sind letztens Endes auch bloß Variablen, also Pointer auf Instanzen) Member eines Forms ist, kannst du in Mehtoden dieses Forms immer mit this oder ohne this drauf zugreifen. Das this brauchst du nur, wenn Namenskonflikte zwischen Membern und Parametern hast. Und das solltest du eh vermeiden.
Nur den Verweis über die vom Builder automatisch angelegte Instanz (also die genauso heißt wie die Formklasse, nur ohne T) solltest du nicht benutzen.

bis bald
akari

Ich dachte immer, dass der this-Zeiger nur für die Leute ist, die sich die Variablen- und Funktionsnamen ihrer Objekte nicht merken können.

volkard

Joe_M. schrieb:

Ich dachte immer, dass der this-Zeiger nur für die Leute ist, die sich die Variablen- und Funktionsnamen ihrer Objekte nicht merken können.

zu 99% richtig, was die verwendung angeht.
aber das 1% am rande reicht, um das sprachmittel zu brauchen:

Window::setVisible(){
   theOneAndOnlyGlobaleListOfVisibleWindowsAndOtherGraphicalElements.insert(this);
}
Window::setInvisible(){
   theOneAndOnlyGlobaleListOfVisibleWindowsAndOtherGraphicalElements.remove(this);
}

1 % ist untertrieben. Braucht man öfters.

volkard

this-that schrieb:

1 % ist untertrieben. Braucht man öfters.

ok. ich mach wenig gui. ich brauch's seltener. hab nicht eingerechnet, daß ich im BCB-forum bin, ich dummerle.

Was die GUI-Objekte im BCB angeht, fällt mir kein einziger Fall ein, wo ich den this Zeiger benötige.
Die ganzen WinAPI Sachen verwendet man im BCB nicht direkt. Dafür hat man ja schließlich die VCL (ok, ganz ohne WinAPI kommt man nicht aus...).

Kann mir jemand ein praktisches Beispiel geben, bei dem ich nicht auf this verzichten kann?

Alexander Kempf

Joe_M. schrieb:

Kann mir jemand ein praktisches Beispiel geben, bei dem ich nicht auf this verzichten kann?

Wir arbeiten öfters mit dem Observer-Pattern, das nach dem Schema abläuft:

Object bietet Methoden zum (De-)Registrieren von Observern:

class Object
{
   public:
      void addObserver(Observer observer);
      void removeObserver(Observer observer);
};

Der Observer muss (wie üblich) irgendeine Form einer update-Methode implementieren:

class Observer  // interface
{
   virtual void update(Object object) = 0;
}

Will sich ein Observer selbst beim Object registrieren, dann tut er das über this:

// irgendwo innerhalb einer Klasse, die Observer implementiert
  Object* object = new Object();
  object->addObserver(this);

Ein Object würde natürlich seine Observer auch über this über Änderungen benachrichtigen:

// irgendwo innerhalb des Objects
   for (int i = 0; i < Observers->Count; ++i)
      Observers->update(this);

Immer wenn sich ein Objekt selbst übergeben muss (das müssen wir ja alle irgendwann), wird es um this kaum herumkommen.

Gruß,

Alexander

ok, danke.
Aber:

Alexander Kempf schrieb:

// irgendwo innerhalb einer Klasse, die Observer implementiert
  Object* object = new Object();
  object->addObserver(this);

Hier hätte statt this auch object angegeben werden können.

Alexander Kempf schrieb:

// irgendwo innerhalb des Objects
   for (int i = 0; i < Observers->Count; ++i)
      Observers->update(this);

Ok, hier kommt man ohne this wohl wirklich nicht aus.

Alexander Kempf

Joe_M. schrieb:

Hier hätte statt this auch object angegeben werden können.

Dann würde sich das Objekt selbst über seine eigene Änderung benachrichtigen?
Oder wie meinst Du das?
Möglich wäre höchstens Object und Observer "von außen" zu erstellen, die update-Problematik
bleibt dann aber bestehen.

Gruß,

Alexander

Sorry, Denkfehler meinerseits, Du hast natürlich recht...