我用C ++编程已经很多年了,但我仍然怀疑一件事。在其他人的代码的许多地方我看到类似的东西:
void Classx::memberfunction()
{
this->doSomething();
}
如果我需要导入/使用该代码,我只需删除 this-> 部分,我从未见过任何损坏或有任何副作用。
void Classx::memberfunction()
{
doSomething();
}
那么,你知道使用这种结构的任何理由吗?
编辑:请注意我在这里谈的是成员函数,而不是变量。我知道当你想区分成员变量和函数参数时,可以使用它。
编辑:明显重复: Are there any reasons not to use "this" ("Self", "Me", ...)?
答案 0 :(得分:37)
唯一真正有所作为的地方是派生类中的模板:
template<typename T>
class A {
protected:
T x;
};
template<typename T>
class B : A<T> {
public:
T get() {
return this->x;
}
};
由于details in the name lookup in C++ compilers,必须明确指出x
是该类的(继承)成员,最容易使用this->x
完成。但这是一个相当深奥的案例,如果你没有模板化的类层次结构,你真的不需要明确地使用this
来访问类的成员。
答案 1 :(得分:27)
如果同一范围内的另一个变量具有相同的名称,则this-&gt;将消除歧义。
void Bar::setFoo(int foo)
{
this->foo = foo;
}
此外,它明确表示您正在引用成员变量/函数。
答案 2 :(得分:8)
如果存在可能使用与您的成员函数同名的宏而且您不确定它是否已被可靠地定义,则保证您触发编译器错误。
不开玩笑,我很确定我必须这样做才是出于这个原因!
答案 3 :(得分:4)
作为“代码原因”,区分本地参数或值(优先级)与成员:
class Foo
{
int member;
void SetMember(int member)
{
this->member = member;
}
}
然而,开始时这很糟糕,通常可以在本地解决。
第二个原因是更多的“环境”:它有时帮助Intellisense过滤我真正想要的东西。但是,当我使用它找到我正在寻找的成员时,我也应该删除它。
所以是的,有充分的理由,但它们都是暂时的(从长远来看也是不好的)。
答案 4 :(得分:2)
在C ++ 11之后到达场景的另一个案例是在lambdas中捕获this
。
你可能有类似的东西:
class Example
{
int x;
public:
std::function<void()> getIncrementor()
{
return [this] () -> void
{
++(this->x);
}
}
};
尽管lambda是在一个类中生成的,但它只能通过捕获它们(如果你的编译器执行C ++ 14)或捕获this
来访问局部变量。在第二种情况下,在lambda体内,根本没有x
,而只有this->x
。
答案 5 :(得分:2)
我认为这主要是为了帮助读者。它明确表示所调用的是对象上的方法,而不是普通的函数。在阅读代码时,知道被调用的函数可以改变当前对象中的字段会很有帮助。例如。
答案 6 :(得分:2)
这实际上是一种风格问题,适用于Java和C#等许多其他语言。有些人更喜欢看到明确的this
(或self
或Me
或其他内容,而其他人则不这样做。只需使用您的风格指南中的任何内容,如果这是您的项目,您就可以决定指南。
答案 7 :(得分:2)
我可以想到可读性,就像使用额外的括号来清楚地表达一样。
答案 8 :(得分:2)
这已被问过几次,但很难搜索它,因为“这个”似乎是搜索的停止词。
这是我自己的问题: Are there any reasons not to use "this" ("Self", "Me", ...)?
答案 9 :(得分:2)
这样做是为了明确表示所使用的变量是一个成员变量而不是局部变量或全局变量。在大多数情况下,这并不是必需的,但如果你在更严格的范围内使用相同名称的声明来代替变量,那么明确有关范围可能会有所帮助。
在我工作过的公司,我们只是将“m_”添加到成员变量中。它有时会很有帮助,我更喜欢使用“this-&gt;”。
编辑: 添加指向the GCC docs的链接,该链接解释了使用此项的情况 - >必须使非依赖查找正常工作。
答案 10 :(得分:1)
我更喜欢它,没有明确的this指针。对于方法调用,它不会添加很多值,但它有助于区分局部变量和成员变量。
答案 11 :(得分:1)
有许多好的答案,但没有一个提到使用这个 - &gt;在源代码中使它更容易阅读,特别是当你正在阅读一些长函数的代码,但即使是一个简短的函数,想象一下代码:
bool Class::Foo()
{
return SomeValue;
}
从查看此代码,您无法清楚地知道SomeValue是什么。它甚至可能是一些#define或静态变量,但如果你写了
bool Class::Foo()
{
return this->SomeValue;
}
你清楚地知道SomeValue是同一类的非静态成员变量。
因此,它不仅可以帮助您确保函数或变量的名称不会与其他名称冲突,而且还可以使其他人更容易阅读和理解源代码,编写自我记录源代码代码有时也很重要。
答案 12 :(得分:1)
我不太清楚确切的情况,但我已经看到(非常罕见)我不得不写“this-&gt; membername”以便用GCC成功编译代码的实例。我记得的只是它与模糊性无关,因此花了一些时间才弄清楚解决方案。相同的代码编译正常,而不使用this-&gt;在Visual Studio中。
答案 13 :(得分:1)
这是你自己的选择。当你使用它时我发现它更清楚。但如果你不喜欢它,你可以省略它。
答案 14 :(得分:1)
消歧:如果您在同一名称空间中有另一个类似的命名函数/变量?我从未见过任何其他原因。
答案 15 :(得分:1)
我不认为它对编译器有所影响,但我总是写这个 - &gt;因为我相信它使代码自我记录。
答案 16 :(得分:0)
我将使用它来隐式调用运算符(下面的返回和参数类型只是构成代码的假人)。
struct F {
void operator[](int);
void operator()();
void f() {
(*this)[n];
(*this)();
}
void g() {
operator[](n);
operator()();
}
};
我更喜欢*this
语法。它的语义略有不同,因为使用*this
不会隐藏与成员同名的非成员运算符函数。