Der this Zeiger - Wann?

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...