É uma boa idéia "#define me (* this)"?

Essa macro pode ser definida em algum cabeçalho global, ou melhor, como um parâmetro da linha de comando do compilador:

#define me (*this)

E algum exemplo 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;  
};

Portanto, em um método de classe, quando acesso um membro da classe, estou sempre usando mee, ao acessar um identificador global, sempre uso ::. Isso fornece ao leitor que não está familiarizado com o código (provavelmente eu mesmo depois de alguns meses) informações localizadas sobre o que é acessado sem a necessidade de procurar em outro lugar. Eu quero definir meporque acho que o uso em this->todos os lugares é muito barulhento e feio. Mas pode #define me (*this)ser considerada uma boa prática de C ++? Existem alguns pontos problemáticos práticos com a memacro? E se você, como programador de C ++, será o leitor de algum código usando a memacro, gostaria ou não?

Edit: Porque muitas pessoas argumentam não especificamente contra o uso me, mas geralmente contra isso explícito. Eu acho que pode não estar claro quais são os benefícios de "isso explícito em todos os lugares".

Quais são os benefícios de "explícito isso em todos os lugares"?

• Como leitor do código, você tem certeza do que é acessado e pode se concentrar em coisas diferentes do que verificar - em algum código distante - que realmente é acessado o que você acha que é acessado.
• Você pode usar a função de pesquisa mais especificamente. A pesquisa " this->x" pode fornecer mais resultados desejados do que apenas a pesquisa " x"
• Quando você está excluindo ou renomeando algum membro, o compilador o notifica de maneira confiável nos locais onde esse membro é usado. (Algumas funções globais podem ter o mesmo nome e existir a chance de introduzir erros se você não estiver usando isso explicitamente).
• Quando você está refatorando o código e tornando a função não membro do membro (para tornar o encapsulamento melhor) explícito, isso mostra o local que você deve editar e pode facilmente substituí-lo pelo ponteiro para a instância da classe fornecida como parâmetro da função não membro
• Geralmente, quando você está alterando o código, há mais possibilidades de erros quando você não está usando isso explícito do que quando você está usando isso explícito em qualquer lugar.
• Explícito, isso é menos barulhento que o explícito "m_" quando você acessa um membro de fora ( object.membervs object.m_member) (graças a @Kaz para identificar este ponto)
• Explícito, isso resolve o problema universalmente para todos os membros - atributos e métodos, enquanto „m_“ ou outro prefixo é praticamente utilizável apenas para atributos.

Gostaria de polir e estender esta lista, me diga se você conhece outras vantagens e casos de uso para explicitar isso em todos os lugares .

Não não é.

Lembre-se do programador que manterá seu código daqui a alguns anos, muito tempo depois de partir para pastos mais ecológicos e seguir as convenções comuns do idioma que você usa. No C ++, você quase nunca precisa escrever this, porque a classe está incluída na ordem de resolução de símbolos e, quando um símbolo é encontrado no escopo da classe, this->está implícito. Portanto, não escreva como todo mundo faz.

Se você costuma ficar confuso sobre quais símbolos vêm do escopo da classe, a abordagem usual é usar o padrão de nomenclatura comum para membros (campos e, às vezes, métodos privados; eu não o vi usado para métodos públicos). Os mais comuns incluem sufixo _ou prefixo com m_ou m.

Então, você deseja criar um novo idioma. Em seguida, faça isso e não aleije o C ++.

Existem várias razões para não fazer isso:

1. Todo padrão de codificação normal sugere evitar macros ( eis o porquê )
2. É mais difícil manter o código com essas macros. Todo mundo que programa em C ++ sabe o que thisé e, ao adicionar essa macro, você está realmente adicionando uma nova palavra-chave. E se todos apresentarem algo de que gostem? Como seria o código?
3. Você não deve usar (*this).ou this->em tudo, exceto em alguns casos especiais (ver esta resposta e procure por "this->")

Seu código não é diferente do #define R returnque eu vi no código real. Razão? Menos digitação!

Indo um pouco fora do assunto, mas aqui vou expandir o ponto 3 (não use (*this).ou this->em uma classe).

Primeiro de tudo, (*this).ou this->são usados ​​para acessar variáveis-membro ou funções do objeto. Usá-lo não tem sentido e significa mais digitação. Além disso, a leitura desse código é mais difícil, porque há mais texto. Isso significa manutenção mais difícil.

Então, quais são os casos em que você precisa usar this->?

(a) Escolha infeliz do nome do argumento.

Neste exemplo, this->é necessário, pois o argumento tem o mesmo nome que a variável de membro:

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

(b) Ao lidar com modelos e herança (veja isso )

Este exemplo falhará na compilação, porque o compilador não sabe qual variável chamada vpara acessar.

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;
    }
};

Eu sugiro não fazer isso. Isso dá a um leitor que não está familiarizado com sua macro um grande " WTF " sempre que ele vê isso. O código não fica mais legível ao inventar "novas convenções" em detrimento das geralmente aceitas, sem nenhuma necessidade real.

usar isso-> em todo lugar é muito barulhento e feio

Pode parecer isso para você, talvez porque você tenha feito muita programação em linguagens usando a palavra-chave me(Visual Basic, eu acho?). Mas, na verdade, é apenas uma questão de se acostumar com isso - this->é bem curto, e acho que a maioria dos programadores experientes em C ++ discordará da sua opinião. E no caso acima, nem o uso this->nem o uso de mesão apropriados - você obtém a menor quantidade de confusão, deixando essas palavras-chave de fora ao acessar membros de dados dentro das funções de membro.

Se você deseja que suas variáveis ​​de membro privadas sejam distinguidas das variáveis ​​locais, adicione algo m_como prefixo ou um sublinhado como sufixo (mas como você pode ver aqui , mesmo essa convenção é "muito barulhenta" para muitas pessoas).

Por favor, não faça isso! Estou tentando lidar com uma grande base de código em que as macros estão por todo o lado para economizar digitação. O lado ruim de redefinir isso para mim é que o pré-processador irá substituí-lo em qualquer lugar, mesmo que isso não esteja no escopo / não se aplique, por exemplo, uma função autônoma, seu colega poderá ter uma variável local chamada me em outro lugar .. Você não terá prazer em depurar ... Você acaba tendo macros que não podem ser usadas em todos os escopos.

NÃO!

Imagine a confusão que ocorrerá se alguém # incluir esse cabeçalho, sem saber o seu truque, e em outro lugar do arquivo eles tiverem uma variável ou função chamada "eu". Eles ficariam terrivelmente confusos com qualquer mensagem de erro inescrutável que seria impressa.