¿Es una buena idea "# definirme (* esto)"?

Esta macro se puede definir en algún encabezado global, o mejor, como un parámetro de línea de comando del compilador:

#define me (*this)

Y algún ejemplo de uso:

some_header.h:

inline void Update()
{
    /* ... */
}

main.cpp:

#include "some_header.h"

class A {
public:
    void SetX(int x)
    {
        me.x = x;   
        me.Update(); 
    }

    void SomeOtherFunction()
    {
        ::Update();
    }

    /*
        100 or more lines
        ... 
    */

    void Update()
    {
        // ... 
    }

    int x;  
};

Entonces, en un método de clase cuando accedo a un miembro de la clase, siempre estoy usando me, y cuando accedo a un identificador global que siempre uso ::. Esto le da al lector que no está familiarizado con el código (probablemente yo mismo después de unos meses) información localizada de lo que se accede sin la necesidad de buscar en otro lado. Quiero definirlo meporque encuentro que usarlo en this->todas partes es demasiado ruidoso y feo. ¿Pero puede #define me (*this)considerarse una buena práctica de C ++? ¿Hay algunos puntos problemáticos prácticos con la memacro? Y si usted como programador de C ++ será el lector de algún código utilizando la memacro, ¿le gustaría o no?

Editar: Debido a que muchas personas argumentan no específicamente contra el uso me, pero generalmente contra explícito esto. Creo que puede no estar claro cuáles son los beneficios de "explícito esto en todas partes".

¿Cuáles son los beneficios de "explícito esto en todas partes"?

• Como lector del código, tiene la certeza de a qué se accede y puede concentrarse en diferentes cosas que verificar, en algún código distante, que realmente se accede a lo que cree que se accede.
• Puede usar la función de búsqueda más específicamente. La búsqueda " this->x" puede proporcionarle más resultados deseados que solo la búsqueda " x"
• Cuando elimina o cambia el nombre de algún miembro, el compilador le notifica de manera confiable en los lugares donde se usa este miembro. (Algunas funciones globales pueden tener el mismo nombre y existe la posibilidad de que pueda introducir un error si no está usando esto explícitamente).
• Cuando refactoriza el código y hace explícita la función no miembro del miembro (para hacer una mejor encapsulación), esto le muestra el lugar que debe editar y puede reemplazarlo fácilmente con el puntero a la instancia de la clase dada como parámetro de función no miembro
• En general, cuando está cambiando el código, hay más posibilidades de errores cuando no está usando esto explícito que cuando está usando esto explícito en todas partes.
• Explícito, esto es menos ruidoso que "m_" explícito cuando está accediendo al miembro desde afuera ( object.membervs object.m_member) (gracias a @Kaz por detectar este punto)
• Explícitamente, esto resuelve el problema universalmente para todos los miembros: atributos y métodos, mientras que "m_" u otro prefijo se puede usar prácticamente solo para atributos.

Me gustaría pulir y ampliar esta lista, dígame si conoce otras ventajas y use casos para explícito esto en todas partes .

No, no es.

Tenga en cuenta al programador que mantendrá su código dentro de varios años, mucho después de que se haya ido a pastos más verdes y siga las convenciones comunes del lenguaje que usa. En C ++, casi nunca tiene que escribir this, porque la clase se incluye en el orden de resolución de símbolos y cuando un símbolo se encuentra en el alcance de la clase, this->está implícito. Así que no lo escribas como todos lo hacen.

Si a menudo se confunde qué símbolos provienen del alcance de la clase, el enfoque habitual es usar un patrón de nomenclatura común para los miembros (campos y, a veces, métodos privados; no lo he visto utilizado para métodos públicos). Los comunes incluyen sufijos _o prefijos con m_o m.

Entonces, quieres crear un nuevo idioma. Luego hazlo y no paralices C ++.

Hay varias razones para no hacerlo:

1. Cada estándar de codificación normal sugerirá evitar las macros ( aquí está la razón )
2. Es más difícil mantener el código con tales macros. Todos los que programan en C ++ saben lo que thises, y al agregar dicha macro, en realidad están agregando una nueva palabra clave. ¿Qué pasa si todos presentan algo que les gusta? ¿Cómo se vería el código?
3. No debe usarlo (*this).o no usarlo this->, excepto en algunos casos especiales (vea esta respuesta y busque "this->")

Su código no es diferente del #define R returnque vi en el código real. ¿Razón? ¡Menos tipeo!

Yendo un poco fuera del tema, pero aquí voy a ampliar el punto 3 (no usar (*this).o this->en una clase).

En primer lugar, (*this).o this->se utilizan para acceder a las variables miembro o funciones del objeto. Usarlo no tiene sentido y significa escribir más. Además, leer dicho código es más difícil porque hay más texto. Eso significa un mantenimiento más difícil.

Entonces, ¿cuáles son los casos en los que tiene que usar this->?

(a) Selección desafortunada del nombre del argumento.

En este ejemplo, this->es obligatorio, ya que el argumento tiene el mismo nombre que la variable miembro:

struct A {
  int v;
  void foo( int v ) {
    this->v =v;
  }
};

(b) Cuando se trata de plantillas y herencia (ver esto )

Este ejemplo no se compilará, porque el compilador no sabe a qué variable se llama vpara acceder.

template< typename T >
struct A {
  A(const T& vValue):v(vValue){}

  T v;
};

template< typename T >
struct B : A<T>
{
    B(const T& vValue):A<T>(vValue){}

    void foo( const T & newV ) {
      v = newV;
    }
};

Sugiero no hacer esto. Esto le da a un lector que no está familiarizado con su macro un gran " WTF " cada vez que ve esto. El código no se vuelve más legible al inventar "nuevas convenciones" sobre las generalmente aceptadas sin ninguna necesidad real.

usar esto-> en todas partes es demasiado ruidoso y feo

Eso puede parecerle así, tal vez porque hizo mucha programación en lenguajes usando la palabra clave me(¿Visual Basic, supongo?). Pero, de hecho, es solo una cuestión de acostumbrarse, this->es bastante corto, y creo que la mayoría de los programadores experimentados de C ++ no estarán de acuerdo con su opinión. Y en el caso anterior, ni el uso this->ni el uso de mees apropiado: obtienes la menor cantidad de desorden al dejar esas palabras clave al acceder a los miembros de datos dentro de las funciones de miembro.

Si desea que sus variables de miembros privados se distingan de las locales, agregue algo m_como un prefijo o un guión bajo como sufijo (pero como puede ver aquí , incluso esta convención es "demasiado ruidosa" para muchas personas).

Por favor no lo hagas! Estoy tratando de hacer frente a una gran base de código donde las macros están por todas partes para guardar la escritura. Lo malo de redefinir esto para mí es que el preprocesador lo reemplazará en todas partes, incluso cuando esto no esté dentro del alcance / no se aplique, por ejemplo, una función independiente, su colega colega podría tener una variable local llamada en otro lugar ... (s) no será feliz depurando ... Terminas teniendo macros que no puedes usar en todos los ámbitos.

¡NO!

Solo imagine la confusión que ocurrirá si alguien # incluye ese encabezado, sin conocer su truco, y en otra parte de su archivo tienen una variable o función llamada "yo". Estarían terriblemente confundidos por cualquier mensaje de error inescrutable que se imprima.