Est-ce une bonne idée de «# me définir (* ceci)»?

Cette macro peut être définie dans un en-tête global, ou mieux, en tant que paramètre de ligne de commande du compilateur:

#define me (*this)

Et un exemple d'utilisation:

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

Ainsi, dans une méthode de classe lorsque j'accède à un membre de la classe, j'utilise toujours meet lorsque j'accède à un identifiant global, j'utilise toujours ::. Cela donne au lecteur qui n'est pas familier avec le code (probablement moi-même après quelques mois) des informations localisées de ce qui est accessible sans avoir besoin de chercher ailleurs. Je veux définir mecar je trouve l'utilisation this->partout trop bruyante et laide. Mais peut- #define me (*this)on considérer comme une bonne pratique C ++? Y a-t-il des points pratiques problématiques avec la memacro? Et si vous, en tant que programmeur C ++, serez le lecteur de code à l'aide de la memacro, cela vous plaira ou non?

Edit: Parce que beaucoup de gens ne soutiennent pas spécifiquement contre l'utilisation me, mais contre expliquent généralement cela. Je pense qu'il n'est peut-être pas clair quels sont les avantages de «l'expliciter partout».

Quels sont les avantages de "l'expliciter partout"?

• En tant que lecteur du code, vous avez la certitude de ce qui est accédé et vous pouvez vous concentrer sur des choses différentes que de vérifier - dans un code distant - que vous avez réellement accès à ce que vous pensez être accédé.
• Vous pouvez utiliser la fonction de recherche plus spécifiquement. La recherche " this->x" peut vous donner plus de résultats que la recherche " x"
• Lorsque vous supprimez ou renommez un membre, le compilateur vous avertit de manière fiable aux endroits où ce membre est utilisé. (Certaines fonctions globales peuvent avoir le même nom et exister, vous pouvez introduire une erreur si vous n'utilisez pas cela explicitement).
• Lorsque vous refactorisez du code et rendez explicite la fonction non membre à partir d'un membre (pour une meilleure encapsulation), cela vous montre où vous devez modifier et vous pouvez facilement le remplacer par un pointeur sur l'instance de classe donnée comme paramètre de fonction non membre
• Généralement, lorsque vous modifiez du code, il y a plus de possibilités d'erreurs lorsque vous n'utilisez pas cela explicitement que lorsque vous utilisez cela explicitement partout.
• Explicite, c'est moins bruyant que «m_» explicite lorsque vous accédez à un membre de l'extérieur ( object.membervs object.m_member) (merci à @Kaz de repérer ce point)
• Explicitement, cela résout le problème universellement pour tous les membres - attributs et méthodes, alors que «m_» ou un autre préfixe n'est pratiquement utilisable que pour les attributs.

Je voudrais peaufiner et étendre cette liste, dites-moi si vous connaissez d'autres avantages et utilisez des cas pour l'expliquer partout .

Non, ça ne l'est pas.

Attention au programmeur qui maintiendra votre code plusieurs années à partir de maintenant longtemps après votre départ pour des pâturages plus verts et suivra les conventions courantes du langage que vous utilisez. En C ++, vous n'avez presque jamais à écrire this, car la classe est incluse dans l'ordre de résolution des symboles et lorsqu'un symbole est trouvé dans la portée de la classe, cela this->est implicite. Donc, ne l'écrivez pas comme tout le monde.

Si vous confondez souvent les symboles provenant de la portée de la classe, l'approche habituelle consiste à utiliser un modèle de dénomination commun pour les membres (champs et méthodes parfois privées; je ne l'ai pas vu utilisé pour les méthodes publiques). Les plus courants incluent le suffixe avec _ou le préfixe avec m_ou m.

Donc, vous voulez créer une nouvelle langue. Faites-le ensuite et ne paralysez pas C ++.

Il y a plusieurs raisons de ne pas le faire:

1. Chaque norme de codage normale suggérera d'éviter les macros ( voici pourquoi )
2. Il est plus difficile de maintenir le code avec de telles macros. Tout le monde qui programme en C ++ sait ce que thisc'est, et en ajoutant une telle macro, vous ajoutez en fait un nouveau mot-clé. Et si chacun présente quelque chose qu'il aime? À quoi ressemblerait le code?
3. Vous ne devriez pas utiliser (*this).ou pas this->du tout, sauf dans certains cas spéciaux (voir cette réponse et recherchez "this->")

Votre code n'est pas différent de celui #define R returnque j'ai vu dans le code réel. Raison? Moins de frappe!

Aller légèrement hors sujet, mais ici je vais développer le point 3 (ne pas utiliser (*this).ou this->en cours).

Tout d'abord, (*this).ou this->sont utilisés pour accéder aux variables membres ou aux fonctions de l'objet. Son utilisation n'a aucun sens et signifie plus de frappe. De plus, la lecture d'un tel code est plus difficile, car il y a plus de texte. Cela signifie un entretien plus difficile.

Alors, quels sont les cas où vous devez utiliser this->?

(a) Choix malheureux du nom de l'argument.

Dans cet exemple, this->est obligatoire, car l'argument a le même nom que la variable membre:

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

(b) Lorsqu'il s'agit de modèles et d'héritage (voir ceci )

Cet exemple ne parviendra pas à compiler, car le compilateur ne sait pas à quelle variable nommée vaccéder.

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

Je suggère de ne pas faire ça. Cela donne à un lecteur qui n'est pas familier avec votre macro un gros " WTF " chaque fois qu'il le voit. Le code n'est pas plus lisible lorsque l'on invente de "nouvelles conventions" par rapport à celles généralement acceptées sans aucun besoin réel.

utiliser ça-> partout est trop bruyant et moche

Cela peut vous sembler vrai, peut-être parce que vous avez fait beaucoup de programmation dans les langages en utilisant le mot-clé me(Visual Basic, je suppose?). Mais en fait, il s'agit simplement de s'y habituer - this->c'est assez court, et je pense que la plupart des programmeurs C ++ expérimentés seront en désaccord avec votre opinion. Et dans le cas ci-dessus, ni l'utilisation this->ni l'utilisation de men'est appropriée - vous obtenez le plus petit encombrement en omettant ces mots clés lors de l'accès aux membres de données à l'intérieur des fonctions membres.

Si vous voulez que vos variables membres privées soient distinguées des variables locales, ajoutez quelque chose de lien m_comme préfixe, ou un trait de soulignement comme suffixe (mais comme vous pouvez le voir ici , même cette convention est "trop ​​bruyante" pour beaucoup de gens).

Veuillez ne pas le faire! J'essaie de faire face à une grande base de code où les macros sont partout pour enregistrer la frappe. La mauvaise chose à redéfinir cela pour moi est que le préprocesseur le remplacera partout même lorsque cela n'est pas dans la portée / ne s'applique pas, par exemple une fonction autonome, votre collègue peut avoir une variable locale qui m'appelle ailleurs. . (s) il ne sera pas content de déboguer ... Vous finissez par avoir des macros que vous ne pouvez pas utiliser dans toutes les étendues.

NON!

Imaginez la confusion qui se produira si quelqu'un # inclut cet en-tête, ne connaissant pas votre astuce, et ailleurs dans son fichier, il a une variable ou une fonction appelée "moi". Ils seraient horriblement confus par tout message d'erreur impénétrable qui serait imprimé.