solos rasgos problemas porque los las genios genio fisicas estan enamoran describe comunes caracteristicas adultos c++

c++ - rasgos - ¿Hay alguna razón para usar esto->



problemas de los genios (17)

Como "razón del código", para distinguir un parámetro local o valor (que tiene prioridad) de un miembro:

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

Sin embargo, eso es una mala práctica para empezar, y generalmente se puede resolver localmente.

La segunda razón es más "entorno": a veces ayuda a Intellisense a filtrar lo que realmente estoy buscando. Sin embargo, también creo que cuando use esto para encontrar el miembro que estoy buscando también debería eliminarlo.

Entonces, sí, hay buenas razones, pero todas son temporales (y malas a largo plazo).

Programé en C ++ durante muchos años y todavía tengo dudas sobre una cosa. En muchos lugares, en otras personas, el código veo algo así como:

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

Si necesito importar / usar ese código, simplemente elimino la parte this-> y nunca he visto nada roto o que tenga algunos efectos secundarios.

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

Entonces, ¿sabe alguna razón para usar tal construcción?

EDITAR: Tenga en cuenta que estoy hablando de funciones de miembros aquí, no de variables. Entiendo que se puede usar cuando quiera hacer una distinción entre una variable miembro y un parámetro de función.

EDIT: duplicado aparente: ¿Hay alguna razón para no usar "this" ("Self", "Me", ...)?


Creo que es principalmente como una ayuda para el lector. Hace explícito que lo que se llama es un método en el objeto, y no una función ordinaria. Al leer el código, puede ser útil saber que la función llamada puede cambiar campos en el objeto actual, por ejemplo.


Desambiguación: ¿en caso de que tenga otra función / variable de denominación similar en el mismo espacio de nombres? Nunca he visto el uso por ninguna otra razón.


El único lugar donde realmente hace una diferencia es en plantillas en clases derivadas:

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

Debido a los detalles en la búsqueda de nombres en los compiladores de C ++ , debe aclararse explícitamente que x es un miembro (heredado) de la clase, más fácil de hacer con this->x . Pero este es un caso bastante esotérico, si no tiene jerarquías de clases con plantillas, realmente no necesita usar this explícitamente para acceder a los miembros de una clase.


Es tu propia elección. Lo encuentro más claro cuando usas esto. Pero si no te gusta, puedes omitirlo.


Lo prefiero sin el explícito este puntero también. Para llamadas de método, no agrega mucho valor, pero ayuda a distinguir las variables locales de las variables de miembro.


No creo que marque la diferencia para el compilador, pero siempre escribo esto-> porque creo que hace que el código se auto-documente.


No recuerdo exactamente las circunstancias exactas, pero he visto casos (muy raros) en los que tuve que escribir "this-> membername" para compilar con éxito el código con GCC. Todo lo que recuerdo es que no estaba relacionado con la ambigüedad y, por lo tanto, me tomó un tiempo encontrar la solución. El mismo código compilado bien sin usar this-> en Visual Studio.


Para garantizar que desencadena errores de compilación si hay una macro que podría definirse con el mismo nombre que su función de miembro y no está seguro si ha sido indefinidamente definida.

No es broma, ¡estoy bastante seguro de que he tenido que hacer exactamente esto por esa razón!


Puedo pensar en legibilidad como cuando usas paréntesis adicionales para aclarar las cosas.


Si hay otra variable en el mismo ámbito con el mismo nombre, this-> eliminará la ambigüedad.

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

También deja en claro que se está refiriendo a una variable / función miembro.


Esto se hace para ser explícito sobre el hecho de que la variable que se utiliza es una variable miembro en oposición a una variable local o global. No es necesario en la mayoría de los casos, pero ser explícito sobre el alcance podría ser útil si ha superado la variable con una declaración del mismo nombre en un ámbito más estricto.

En las empresas en las que he trabajado, acabamos de anteponer "m_" a las variables de los miembros. A veces puede ser útil, y prefiero usar "this->".

Editar: Agregar un enlace a los documentos de GCC , que explican un caso donde el uso de this-> es necesario para que una búsqueda no dependiente funcione correctamente.


Lo usaré para llamar operadores implícitamente (los tipos de retorno y parámetros a continuación son solo maniquíes para inventar el código).

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

Me gusta *this sintaxis más. Tiene una semántica ligeramente diferente, en la que usar *this no ocultará las funciones del operador no miembro con el mismo nombre que un miembro.


Esto es realmente una cuestión de estilo y se aplica a muchos otros lenguajes como Java y C #. Algunas personas prefieren ver this explícito (o self , o Me , o lo que sea) y otros no. Simplemente haga lo que esté en sus pautas de estilo, y si es su proyecto, puede decidir las pautas.


Hay muchas buenas respuestas, pero ninguna de ellas menciona que usar this-> en el código fuente hace que sea más fácil de leer, especialmente cuando estás leyendo un código de alguna función larga, pero incluso una función corta, imagina un código:

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

al mirar este código, no se puede saber claramente qué es SomeValue. Podría ser incluso alguna variable #define, o static, pero si escribe

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

usted sabe claramente que SomeValue es una variable miembro no estática de la misma clase.

Por lo tanto, no solo le ayuda a asegurarse de que el nombre de sus funciones o variables no entre en conflicto con otros nombres, sino que también facilita que otros lean y comprendan el código fuente, a veces se escribe un código fuente de autoedición. muy importante también


Otro caso, que ha llegado a las escenas después de C ++ 11 está en lambdas donde se captura esto.

Puede tener algo como:

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

Aunque su lambda se genera dentro de una clase, solo tendrá acceso a variables locales al capturarlas (si su compilador hace C ++ 14) o capturar this . En el segundo caso, dentro del cuerpo de lambda, simplemente no hay x , sino solo this->x .