Wenn ich diesen Code importieren/verwenden muss, entferne ich einfach die dies-> Teil, und ich habe noch nie gesehen, dass etwas kaputt gegangen ist oder irgendwelche Nebenwirkungen hatte.
void Classx::memberfunction()
{
doSomething();
}
Kennen Sie also einen Grund, ein solches Konstrukt zu verwenden?
EDIT: Bitte beachten Sie, dass ich hier über Memberfunktionen spreche, nicht über Variablen. Ich verstehe, dass es verwendet werden kann, wenn Sie zwischen einer Membervariablen und einem Funktionsparameter unterscheiden möchten.
EDIT: offensichtliches Duplikat: Gibt es Gründe, “this” (“Self”, “Me”, …) nicht zu verwenden?
etw
Der einzige Ort, an dem es wirklich einen Unterschied macht, sind Vorlagen in abgeleiteten Klassen:
template<typename T>
class A {
protected:
T x;
};
template<typename T>
class B : A<T> {
public:
T get() {
return this->x;
}
};
Wegen Details in der Namenssuche in C++-Compilernmuss ausdrücklich darauf hingewiesen werden x ein (geerbtes) Mitglied der Klasse ist, was am einfachsten zu erledigen ist this->x. Dies ist jedoch ein ziemlich esoterischer Fall, wenn Sie keine Klassenhierarchien mit Vorlagen haben, die Sie nicht wirklich explizit verwenden müssen this um auf Mitglieder einer Klasse zuzugreifen.
Wenn es eine andere Variable im selben Gültigkeitsbereich mit demselben Namen gibt, entfernt this-> die Mehrdeutigkeit.
void Bar::setFoo(int foo)
{
this->foo = foo;
}
Außerdem wird deutlich, dass Sie sich auf eine Member-Variable / Funktion beziehen.
Wenn Sie es so verwenden, ist es meiner Meinung nach ein Pflaster für eine schlechte Namenskonvention. Es bringt den Code unnötig durcheinander.
– Joris Timmermans
23. Februar 2009 um 11:12 Uhr
Ich habe keine Frage zu Variablen gestellt, das ist ein bekanntes Problem. Ich fragte nach Mitgliedsfunktionen.
– Milan Babuškov
23. Februar 2009 um 11:33 Uhr
@MadKeithV: Dies-> ist eine sprach- und werkzeugunterstützte Namenskonvention, im Gegensatz zum Präfix m_.
– MSalter
23. Februar 2009 um 11:38 Uhr
Und es macht immer noch nicht klar, was der Umfang von foo auf RHS ist.
– Milan Babuškov
25. Februar 2010 um 22:27 Uhr
Um sicherzustellen, dass Sie Compilerfehler auslösen, wenn ein Makro mit demselben Namen wie Ihre Memberfunktion definiert ist und Sie nicht sicher sind, ob es zuverlässig undefiniert ist.
Kein Scherz, ich bin mir ziemlich sicher, dass ich genau das aus diesem Grund tun musste!
Wenn es auf eine Funktion angewendet wird, garantiert es, welche Version einer möglicherweise virtuellen Funktion aufgerufen wird, verhindert Polymorphismus und wird häufig verwendet, um ein übergeordnetes Element einer überschriebenen Funktion aufzurufen. Es ist KEIN sicheres Äquivalent zu this->doSomething().
– Andy Dent
3. Dezember 2009 um 11:30 Uhr
Das stimmt, ich hatte diesen Fall vergessen! Danke Andi.
– Rehno-Lindeque
3. Dezember 2009 um 14:23 Uhr
Als “Codegrund”, um einen lokalen Parameter oder Wert (der Vorrang hat) von einem Mitglied zu unterscheiden:
class Foo
{
int member;
void SetMember(int member)
{
this->member = member;
}
}
Das ist jedoch von Anfang an eine schlechte Praxis und kann normalerweise lokal gelöst werden.
Der zweite Grund ist mehr “Umgebung”: Es hilft Intellisense manchmal, das zu filtern, wonach ich wirklich suche. Ich denke jedoch auch, wenn ich dies verwende, um das gesuchte Mitglied zu finden, sollte ich dies auch entfernen.
Also ja, es gibt gute Gründe, aber sie sind alle vorübergehend (und auf lange Sicht schlecht).
Ich kann mir Lesbarkeit vorstellen, wenn Sie zusätzliche Klammern verwenden, um die Dinge klarer zu machen.
entspannen
Ich denke, es ist hauptsächlich eine Hilfe für den Leser. Es macht deutlich, dass das, was aufgerufen wird, eine Methode für das Objekt ist und keine gewöhnliche Funktion. Beim Lesen von Code kann es hilfreich sein zu wissen, dass die aufgerufene Funktion beispielsweise Felder im aktuellen Objekt ändern kann.
Ikke
Es ist Ihre eigene Wahl. Ich finde es klarer, wenn Sie dies verwenden. Aber wenn es dir nicht gefällt, kannst du es weglassen.
9157000cookie-checkGibt es einen Grund, dies zu verwenden->yes