Der this zeiger

guten abend

ich würde gerne wissen wann der this zeiger eigentlich zum einsatz kommen sollte. ich weiss durchaus was der this zeiger ist und wie man den syntax verwendet. aber wirklich sinn ausser in einem fall habe ich noch keinen gefunden.

nehmen wir als beispiel am besten ein array mit 10 objekten einer klasse mit dem wir dann arbeiten. wenn ich jetzt z.B. in einem methoden rumpf auf klassen-elemente zugreiffe, wird der this zeiger ja garnicht benötigt, da ohne der scope verwendung bereits das element angesprochen wird, welches zum this objekt gehört. beispiel:

void MyClass::MyMethod()
{
	this->var = "Hello";
	//.. ist genau gleich bedeutend mit...
	var = "Hello";
}

hier macht für mich der this zeiger also keinen sinn. ich denke auch wenn ich eine methode im methoden rumpf aufrufe, wird die methode des this objektes aufgerufen. es ist also nicht notwendig folgendes zu schreiben:

void MyClass::MyMethod()
{
	this->DoAnything();
	//.. ist genau gleich bedeutend mit...
	DoAnything();
}

insofern. wann macht ein this zeiger sinn? und speziell: wann gibt es konflikte, wenn man den this zeiger nicht benutzt?

drakon

Hatten wir erst gerade:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-228857-and-highlight-is-this+zeiger.html

achja und hier:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-227871-and-highlight-is-this+zeiger.html

aah. alles klar nun. grundsätzlich werden this zeiger nur dann gebraucht, wenn man innerhalb einer methode des this objektes eine methode einer anderen klasse aufruft und diese erwartet als parameter einen zeiger auf das objekt.

oder aber wenn man z.B. explizit auf das klassenelement zugreiffen möchte, wenn z.B. der variablen name der methode gleichnamig ist, oder? z.B.

void MyClass::Methode(int i)
{
    this->i = i;
}

korrekt? ich muss zugeben ich habe immer einen m_ prefix für sollche situationen verwendet. das werde ich nun aber ändern :xmas1:

drakon

Das mit dem Namen überdecken kannst du auch ohne den this-Zeiger lösen.

Aber das sind noch :
- der explizite Destrukor-Aufruf.
- delete this
- Vergleich mit this für die Implementierung des =-Operators

Das mit dem Namen überdecken kannst du auch ohne den this-Zeiger lösen.

und wie?

Nexus

thissy schrieb:

ich muss zugeben ich habe immer einen m_ prefix für sollche situationen verwendet. das werde ich nun aber ändern :xmas1:

Ich finde es nicht gut, Namenskonflikte herbeizuführen, wenn vorher ja alles gut ging. Die m_ -Schreibweise ist durchaus legitim (oder halt My , my , ...), ich würde die beibehalten. Ich selber handhabe es selber oft so, dass ich Parametern (in Konstruktoren und Settern) ein New -Präfix vorne dran hänge, aber das ist natürlich Geschmackssache.

drakon schrieb:

Aber das sind noch :
- der explizite Destrukor-Aufruf.
- delete this
- Vergleich mit this für die Implementierung des =-Operators

Wobei man die ersten beiden normalerweise nicht braucht und dabei gut aufpassen muss, was man tut. Nicht, dass er noch auf dumme Ideen kommt...

Den dritten brauche ich persönlich auch nicht, da ich den Zuweisungsoperator meistens mit Copy&Swap implementiere. Aber Selbstzuweisungen kommen ja sowieso relativ selten vor...

drakon

thissy schrieb:

Das mit dem Namen überdecken kannst du auch ohne den this-Zeiger lösen.

und wie?

Steht doch in einem meiner Links..

class Bar
{
    int a;
     void foo(int a)
     {
         Bar::a = a; // temp. a in das member-a zuweisen
     }
};

Den dritten brauche ich persönlich auch nicht, da ich den Zuweisungsoperator meistens mit Copy&Swap implementiere. Aber Selbstzuweisungen kommen ja sowieso relativ selten vor...

Den ersten Satzt verstehe ich, aber der zweite?!
Willst du damit sagen, dass man den Fall nicht miteinbeziehen muss?

this kann beispielsweise in Bäumen ein Kind seinem Vater gegenüber identifizieren.

Nexus

drakon schrieb:

Willst du damit sagen, dass man den Fall nicht miteinbeziehen muss?

Kommt auch drauf an. Wenn dadurch, dass man Selbstzuweisungen nicht separat abfragt, kein Nachteil bezüglich der Semantik entsteht (also falsche Zuweisung), ist die Abfrage eigentlich vernachlässigbar. Ich meine, der durch die daraus folgenden Kopien entstehende Performancenachteil hat der User dann selbst zu verschulden.

Wenn man aber dadurch z.B. Exceptionsicherheit aufs Spiel setzt, ist das wieder etwas anderes.

drakon

Nexus schrieb:

drakon schrieb:

Willst du damit sagen, dass man den Fall nicht miteinbeziehen muss?

Kommt auch drauf an. Wenn dadurch, dass man Selbstzuweisungen nicht separat abfragt, kein Nachteil bezüglich der Semantik entsteht (also falsche Zuweisung), ist die Abfrage eigentlich vernachlässigbar. Ich meine, der durch die daraus folgenden Kopien entstehende Performancenachteil hat der User dann selbst zu verschulden.

Wenn man aber dadurch z.B. Exceptionsicherheit aufs Spiel setzt, ist das wieder etwas anderes.

Also ich erstelle für eine Klasse, die lediglich sich selbst verwaltenden Objekte besitzt keinen Kopierkonstruktor. Bei allem anderem muss man mit problematischen Selbstzuweisungen rechnen..