В некоторых случаях использование this необходимо , а в других случаях использование указателя this является одним из способов решения проблемы.
1) Доступные альтернативы : Чтобы устранить неоднозначность между локальными переменными и членами класса, , как показано @ ASk .
2) Нет Альтернатива: Для возврата указателя или ссылки на this из функции-члена. Это часто делается (и должно быть сделано) при перегрузке operator+, operator-, operator= и т. Д .:
class Foo
{
Foo& operator=(const Foo& rhs)
{
return * this;
}
};
Это позволяет использовать идиому, известную как « цепочка методов », где вы выполняете несколько операций над объектом в одной строке кода. Такие как:
Student st;
st.SetAge (21).SetGender (male).SetClass ("C++ 101");
Некоторые считают этот принцип, другие считают его мерзостью. Считай меня в последней группе.
3) Нет Альтернатива: Для разрешения имен в зависимых типах. Это появляется при использовании шаблонов, как в этом примере:
#include <iostream>
template <typename Val>
class ValHolder
{
private:
Val mVal;
public:
ValHolder (const Val& val)
:
mVal (val)
{
}
Val& GetVal() { return mVal; }
};
template <typename Val>
class ValProcessor
:
public ValHolder <Val>
{
public:
ValProcessor (const Val& val)
:
ValHolder <Val> (val)
{
}
Val ComputeValue()
{
// int ret = 2 * GetVal(); // ERROR: No member 'GetVal'
int ret = 4 * this->GetVal(); // OK -- this tells compiler to examine dependant type (ValHolder)
return ret;
}
};
int main()
{
ValProcessor <int> proc (42);
const int val = proc.ComputeValue();
std::cout << val << "\n";
}
4) Доступные альтернативы: Как часть стиля кодирования, документировать, какие переменные являются переменными-членами, а не локальными. Я предпочитаю другую схему именования, где у членов varibales никогда не может быть того же имени, что и у местных. В настоящее время я использую mName для членов и name для местных жителей.