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?

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

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:

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?

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

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?

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