C’è qualche ragione per usare questo->

Ho programmato in C ++ per molti anni e ho ancora dubbi su una cosa. In molti posti nel codice di altre persone vedo qualcosa del tipo:

void Classx::memberfunction() { this->doSomething(); } 

Se devo importare / utilizzare quel codice, rimuovo semplicemente questa> parte, e non ho mai visto nulla di rotto o di avere effetti collaterali.

 void Classx::memberfunction() { doSomething(); } 

Quindi, sai qualche motivo per usare tale costrutto?

EDIT: Si noti che sto parlando delle funzioni membro qui, non delle variabili. Capisco che possa essere usato quando vuoi fare una distinzione tra una variabile membro e un parametro di funzione.

EDIT: duplicato apparente: ci sono dei motivi per non usare “this” (“Self”, “Me”, …)?

Per garantire l’triggerszione degli errori del compilatore se esiste una macro che potrebbe essere definita con lo stesso nome della funzione membro e non si è certi se è stata definita indefinitamente.

Non sto scherzando, sono abbastanza sicuro di aver fatto esattamente questo per questo motivo!

L’unico posto in cui fa davvero la differenza è nei template nelle classi derivate:

 template class A { protected: T x; }; template class B : A { public: T get() { return this->x; } }; 

A causa dei dettagli nella ricerca del nome nei compilatori C ++ , è necessario chiarire esplicitamente che x è un membro (ereditato) della class, fatto più facilmente con this->x . Ma questo è un caso piuttosto esoterico, se non si dispone di gerarchie di classi basate su modelli, non è necessario utilizzarlo esplicitamente per accedere ai membri di una class.

Se c’è un’altra variabile nello stesso scope con lo stesso nome, questa -> rimuoverà l’ambiguità.

 void Bar::setFoo(int foo) { this->foo = foo; } 

Inoltre chiarisce che stai facendo riferimento a una variabile / funzione membro.

Come “motivo del codice”, per distinguere un parametro locale o un valore (che ha la precedenza) da un membro:

 class Foo { int member; void SetMember(int member) { this->member = member; } } 

Tuttavia, questo è un aspetto poco positivo, e di solito può essere risolto localmente.

La seconda ragione è più “ambiente”: a volte aiuta Intellisense a filtrare ciò che sto veramente cercando. Comunque, anche io quando lo uso per trovare il membro che sto cercando, dovrei anche rimuoverlo.

Quindi sì, ci sono buone ragioni, ma sono tutte temporanee (e cattive a lungo termine).

Posso pensare alla leggibilità come quando usi una parentesi aggiuntiva per chiarire le cose.

Penso che sia principalmente un aiuto per il lettore. Rende esplicito che ciò che viene chiamato è un metodo sull’object e non una funzione ordinaria. Durante la lettura del codice, può essere utile sapere che la funzione chiamata può modificare i campi nell’object corrente, ad esempio.

Questo è stato chiesto un paio di volte, ma è difficile cercarlo perché “questo” sembra essere una parola d’ordine per la ricerca.

Ecco la mia domanda: ci sono dei motivi per non usare “this” (“Self”, “Me”, …)?

Questo viene fatto per essere espliciti sul fatto che la variabile utilizzata è una variabile membro al contrario di una variabile locale o globale. Nella maggior parte dei casi non è necessario, ma essere espliciti riguardo all’ambito può essere utile se hai superato la variabile con una dichiarazione con lo stesso nome in un ambito più stretto.

Alle aziende in cui ho lavorato, abbiamo anteposto “m_” alle variabili membro. A volte può essere utile, e preferisco di gran lunga usare “questo->”.

Modifica: aggiunta di un collegamento ai documenti GCC , che spiega un caso in cui l’uso di questo-> è necessario per ottenere una ricerca non dipendente che funzioni correttamente.

Questa è davvero una questione di stile e si applica a molti altri linguaggi come Java e C #. Alcune persone preferiscono vedere l’esplicito this (o self , o Me , o qualsiasi altra cosa) e altri no. Vai con quello che è nelle tue linee guida di stile, e se è il tuo progetto, devi decidere le linee guida.

Un altro caso, che è arrivato sulle scene dopo C ++ 11, è in lambda dove viene catturato.

Potresti avere qualcosa come:

 class Example { int x; public: std::function getIncrementor() { return [this] () -> void { ++(this->x); } } }; 

Sebbene il tuo lambda sia generato all’interno di una class, avrà solo accesso alle variabili locali catturandole (se il tuo compilatore fa C ++ 14) o acquisendo this . Nel secondo caso, all’interno del corpo di lambda, semplicemente non c’è x , ma solo this->x .

Non penso che faccia la differenza per il compilatore, ma scrivo sempre questo-> perché credo che renda il codice auto-documentabile.

Disambiguazione: nel caso in cui tu abbia un’altra funzione / variabile di denominazione simile nello stesso spazio dei nomi? Non ho mai visto l’utilizzo per nessun altro motivo.

È una tua scelta. Trovo più chiaro quando lo usi. Ma se non ti piace, puoi ometterlo.

Lo preferisco anche senza questo puntatore esplicito. Per le chiamate al metodo non aggiunge molto valore, ma aiuta a distinguere le variabili locali dalle variabili membro.

Non riesco a ricordare le circostanze esatte, ma ho visto (molto raro) casi in cui dovevo scrivere “questo-> nomeutente” per compilare correttamente il codice con GCC. Tutto ciò che ricordo è che non era in relazione all’ambiguità e quindi mi ci è voluto un po ‘per capire la soluzione. Lo stesso codice compilato bene senza usare questo-> in Visual Studio.

Ci sono molte buone risposte, ma nessuno di loro menziona che l’uso di questo-> nel codice sorgente rende più facile la lettura, specialmente quando stai leggendo un codice di qualche funzione lunga, ma anche una funzione breve, immagina un codice:

 bool Class::Foo() { return SomeValue; } 

dall’osservazione di questo codice, non puoi sapere chiaramente cos’è SomeValue. Potrebbe essere anche qualche #define, o variabile statica, ma se scrivi

 bool Class::Foo() { return this->SomeValue; } 

sai chiaramente che SomeValue è una variabile membro non statica della stessa class.

Quindi non ti aiuta solo a garantire che il nome delle tue funzioni o variabili non sia in conflitto con altri nomi, ma rende anche più facile per gli altri leggere e capire il codice sorgente, scrivendo a volte un codice sorgente auto-documentante molto importante pure.

Lo userò per chiamare implicitamente gli operatori (i tipi di ritorno e di parametri sottostanti sono solo dei maniaci per creare il codice).

 struct F { void operator[](int); void operator()(); void f() { (*this)[n]; (*this)(); } void g() { operator[](n); operator()(); } }; 

Mi piace il *this syntax di più. Ha una semantica leggermente diversa, in quanto usando *this non nasconde le funzioni dell’operatore non membro con lo stesso nome di un membro, però.