Wskaźnik this - używać czy nie?

Ostatnio pisząc w Visual C++ przyzwyczaiłem się wszędzie odnosić się do składowych klasy przez wskaźnik this np.

class A 
{
	private:

		int i;

	public:
		A();

		void ustawWypisz(int j);
		void wypisz();
};

A::A() 
{
	this->i = 0;
}

void A::wypisz()
{
	cout << this->i << endl;
}

void A::ustawWypisz(int j)
{
	this->i = j;
	this->wypisz();
	if(j < 100)
		this->ustawWypisz(this->i+1);
}

W Visual C++ pisze się tak wygodnie, gdyż po wpisaniu "this->" pojawia się lista, z której można składową, do której się odwołujemy. Ponadto jest to bardziej przejrzyste, gdyż od razu w kodzie widać, które zmienne i funkcje są składowymi klasy, a które są zmiennymi lokalnymi.

Ponieważ jednak na necie rzadko spotyka się w ten sposób pisany kod - zacząłem się zastanawiać czy takie pisanie kodu nie jest "bad habit" i czy nie niesie to za sobą jakiś niebezpieczeństw np. w odniesieniu do funkcji wirtualnych, wskaźników czy innych...

Nie znalazłem na forum takiej dyskusji, więc zakładam ten temat z zapytaniem o Wasze opinie.

Możesz używać This, nie musisz... Kompilator i tak sam go sobie dopisze,,,

Bo to zło !!

Generalnie ładnie, jednak nie dokonca. Na pierwszy rzut oka wydaje się świetnie i wygodnie jednak tak nie jest. Jeden raz biedziłem się nad kodem przez parę dni dlaczego nie działa, a to wszystko przez this. Miałem funkcje która sprawdzała cos na pewnym obiekcie. Używałem this i się dziwiłem, dlaczego nie zmienia i nie sprawdza zadanego obiektu. Sprawdzało i zmieniało obiekt z którego została wywołana, a nie na tym na którym miała działać, właśnie przez this. Niby trywialne i każdy wie ze tak się dzieje, jednak this zwiększa prawdopodobieństwo błędu wiec należy go eliminować. Stosuje sie to w ekstremalnych przypadkach ze masz 2 takie sam zmienne jednak z klasy druga globalna i wtedy this ma racje bytu - tak raz uratowałem kod kumpla, gdzie on przez 2 tyg. szukał błędu. Może to i podstawy ale czasami gdzieś sie bug wkradnie i masakra. Teraz piszę grę, pare klas. Część graficzną pisze kolega, wszystko ma odpowiedni interface. Naprawdę nieraz dziwimy sie co sie dzieje. Kod jest tak powiązany, że czasami wychodzą samo twórcze powiązania, obiekty, etc. etc. Generalnie takim kodem się juz ciężko zarządza, dodatkowo jak się pisze w zespole, a co dopiero martwić sie thisami, więc ich nie stosujemy, jeden problem z głowy. Dodatkowo this fajnie sie uzywa jak chce sie przekazać, lub zwrócić samego siebie do lub z funkcji.

Ja nie używam, jakoś niewygodnie potem mi się w takim kodzie grzebie.

@lukas_gab nie bardzo rozumiem co ma pisanie this wspólnego z tym że ty z kolegą piszecie projekt w marnym stylu i nie stosujecie tam zasady segregacji interfejsów / zasady jednej odpowiedzialności.
This nigdy nie powoduje problemów (chyba że wstawisz go w złe miejsce, no ale bez przesady...), a czasami jest konieczne go napisac. W większości sytuacji jednak jest to zbędne i nie ma sensu zaciemniać kodu ciagłym dopisywaniem this->

Moja odpowiedź:Tak uzywac i to jak najwięcej :-D :-D , ohh pytałeś o this. Są przypadki kiedy musisz użyć.

Powiedzmy że masz metodę klasy A lub np konstruktor A(char* osoba). Masz też prywatne pole klasy o nazwie osoba. Ja często używam tych samych nazw bo chce aby intelisence podpowiadał mi atrybuty konstruktora które się same opisują.
Wtedy ciało kontruktora

class A
{
char* osoba;
void A(char* osoba)
{
     this->osoba = osoba;
}
} 

Shalom napisał(a)

@lukas_gab nie bardzo rozumiem co ma pisanie this wspólnego z tym że ty z kolegą piszecie projekt w marnym stylu i nie stosujecie tam zasady segregacji interfejsów / zasady jednej odpowiedzialności.
This nigdy nie powoduje problemów (chyba że wstawisz go w złe miejsce, no ale bez przesady...), a czasami jest konieczne go napisac. W większości sytuacji jednak jest to zbędne i nie ma sensu zaciemniać kodu ciagłym dopisywaniem this->

Więc sugerujesz, że jeżeli i tak nie mamy doświadczenia i dobrych nawyków to łatwiej nam będzie martwić się czy na pewno, któryś this pokazuje na cos na co nie chcieliśmy pokazac ? Im mniej problemów sie mnoży tym lepiej, szczególnie jak umiejętności są jeszcze marne.

Swoją drogą to zaciemnienie kodu - raz pisałem funkcje obliczającą pole czworoboku z takiego śmiesznego wzoru i najpierw wrzuciłem wszystko w jedno działanie i jeszcze poprzedziłem thisami Działało, jednak marnie to wyglądało, bo na cały ekran było ;p Po usunięci thisów obszar sie zmniejszył, a i później po podzieleniu tego stworzenia na mniejsze ,ładnie juz wyglądało i czytelnie.

Wszystko zależy od przyjętego "coding convention", czyli umowy jak formatować kod i nadawać nazwę symbolom. Jeśli tak wam wygodniej to się umówcie, że taki macie standard. Moim zdaniem, lepiej już stosować notację węgierską zamiast tego this
Stosowanie jakiegokolwiek standardu kodowania ułatwia czytanie/poprawianie kodu, a jaki standard przyjmiecie, to już nie ma znaczenia.

Czasem this się przydaje. Kiedyś uważałem, że używanie go jest dobre, bo pomaga odznaczyć składowe klasy. Jestem przeciwnikiem notacji węgierskiej (w ogromnej większości przypadków, a w pozostałych też jej nie lubię). Zamiast m_name (m jak member) wolę this->name.

Ale teraz nie ma to już takiego znaczenia. IDE potrafią bez problemu podświetlać składowe klasy innym kolorem. Więc nie trzeba ani dawać przedrostka m_, ani stawiać przed nazwą this. I tak widać, co jest czym.

Z tego powodu coraz częściej spotykam się z ruchem generalnie anty-this (ew. używającym go w konstruktorach i setterach). Na zasadzie: jeśli this jest jedynie redundantne -- nawet wizualnie -- to po co go używać?

Generalnie jednak sam długo używałem this. Chyba jeszcze to robię w niektórych językach. Jak dla mnie używanie this nie jest tragedią, byle tylko robić to konsekwentnie. Albo odwrotnie: nie używać this w ogóle, poza jasno zdefiniowanymi przypadkami, gdy jest przydatne (przesłonięcie).

Co za absurdalna dyskusja.
This musi być tylko jak stosujemy szablony i bez thisa nie działa, w pozostałych przypadkach bez żadnej różnicy. Naprawdę. Co za różnica? To jak rozmowa o kolorach klawiatur.

programista87 napisał(a)

Co za absurdalna dyskusja.
This musi być tylko jak stosujemy szablony i bez thisa nie działa, w pozostałych przypadkach bez żadnej różnicy. Naprawdę. Co za różnica? To jak rozmowa o kolorach klawiatur.

W kontekscie pisania this przed skladowymi zgadzam sie, ze nie ma zadnej roznicy, ale tak czy inaczej kiedys z this skorzystamy, chociazby mamy metode z dwoma parametrami, bedacymi referencjami danej klasy, a przeciazamy jakis operator i chcemy wyslac do tej metody dodatkowej l-value i r-value wyrazenia.
Uniknac sie czasami nie da, ale pisac to tylko dlatego, ze visual pokazuje skladowe i metody...
Moim zdaniem kod sie robi bardziej nieczytelny jak sie te this'y wszedzie daje, a przeciez mozna sobie this napisac raz w tym visualu i juz sie widzi jakie sa te skladowe(ewentualnie skopiowac je do komentarza i wywalic jak sie skonczy pisac dana metode), wiec po problemie, ale tak jak mowie moim zdaniem to tylko oszpeca kod.

Thisa generalnie powinno się używać tylko jeśli zmienna lokalna (a więc także parametr funkcji) przysłania zmienną klasową. W NetBeans wystarczy nacisnąć ctrl+spacja żeby pokazała się lista dostępnych zmiennych. W Visualu też coś takiego jest, nie należy pisać this tylko po to.