「#define me（* this）」をお勧めしますか？

このマクロは、コンパイラのコマンドラインパラメーターとして、グローバルヘッダーで定義することができます。

#define me (*this)

そして、いくつかの使用例：

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

したがって、クラスメンバーにアクセスするときのクラスメソッドでは、常にを使用しme、グローバル識別子にアクセスするときには常に使用します::。これにより、コードに精通していない読者（おそらく数か月後には自分自身）に、他の場所を探す必要なくアクセスされたもののローカライズされた情報が提供されます。どこでもme使用this->するとうるさくてugいため、定義したいです。しかし#define me (*this)、C ++の優れた実践と考えることができますか？meマクロにはいくつかの実用的な問題点がありますか？また、C ++プログラマとして、meマクロを使用するコードの読者になる場合、それを好むか好まないのでしょうか？

編集：多くの人meがを使用して具体的に反論するのではなく、一般的にこれを明示的に反論するため。「どこでもこれを明示する」ことの利点が何であるかは明確ではないと思う。

「どこでもこれを明示する」ことの利点は何ですか？

• コードの読者として、アクセスされるものに確実性があり、検証することとは異なることに集中することができます。
• より具体的に検索機能を使用できます。「検索this->x」のみ検索するよりも、あなたに多くの望んでいた結果を与えることができます「x」
• あるメンバーを削除または名前変更するとき、コンパイラーはこのメンバーが使用されている場所で確実に通知します。（一部のグローバル関数は同じ名前を持ち、明示的なthisを使用していない場合にエラーが発生する可能性があります）。
• コードをリファクタリングし、メンバーから非メンバー関数を明示的に作成すると（カプセル化を改善するため）、編集する必要がある場所が示され、非メンバー関数パラメーターとして指定されたクラスのインスタンスへのポインターに簡単に置き換えることができます
• 一般に、コードを変更するときは、明示的なthisをどこでも使用するときよりも、明示的なthisを使用しないときのエラーの可能性が高くなります。
• 明示的にこれは、外部からメンバーにアクセスしているときの明示的な「m_」よりもノイズが少ない（object.membervs object.m_member）（この点を見つける@Kazに感謝）
• 明示的にこれは、すべてのメンバー（属性とメソッド）の問題を普遍的に解決しますが、「m_」または他のプレフィックスは属性に対してのみ実用的に使用できます。

このリストを洗練して拡張し、他の利点について知っているかどうか、そしてどこでも明示的なthisのユースケースを教えてください。

いいえそうではありません。

あなたがより環境に優しい放牧地を離れてから数年後にあなたのコードを維持し、使用する言語の一般的な慣習に従うプログラマーに注意してください。C ++では、thisクラスはシンボル解決の順序に含まれており、クラススコープでシンボルが見つかった場合this->は暗黙的に示されるため、ほとんど記述する必要はありません。だから、みんながするように書いてはいけない。

クラススコープからのシンボルが混乱することがよくある場合、通常のアプローチでは、メンバー（フィールドおよび場合によってはプライベートメソッド。パブリックメソッドに使用されることはありません）に共通の命名パターンを使用します。一般的なものは、と接尾辞を付ける含める_かを前に置きますm_かm。

そのため、新しい言語を作成します。次に、そうし、C ++に障害を与えないでください。

しない理由はいくつかあります。

1. すべての通常のコーディング標準は、マクロを避けることを提案します（ここに理由があります）
2. そのようなマクロを使用してコードを維持することは困難です。C ++でプログラミングしている人thisは誰でも知っており、そのようなマクロを追加することで、実際に新しいキーワードを追加しています。みんなが好きなものを紹介したらどうでしょうか？コードはどのように見えるでしょうか？
3. いくつかの特別な場合を除き、使用しない(*this).かthis->、まったく使用しないでください（この回答を参照して「this->」を検索してください）

あなたのコードは#define R return、実際のコードで見たとは違いません。理由？タイピングが少ない！

オフトピック少し行くが、ここで私は（使用していない点3に拡大するつもりです(*this).かthis->クラスで）。

まず第一に、(*this).またはthis->オブジェクトのアクセスメンバ変数や関数に使用されています。それを使用することは無意味であり、より多くの入力を意味します。また、テキストが多いため、このようなコードの読み取りはより困難です。つまり、メンテナンスが難しくなります。

だから、あなたが使用しなければならないケースは何this->ですか？

（a）残念ながら引数名の選択。

この例でthis->は、引数がメンバー変数と同じ名前であるため、が必要です。

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

（b）は、テンプレートと継承を扱う場合（参照これを）

この例は、コンパイラがvアクセスする変数の名前を知らないため、コンパイルに失敗します。

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

これをしないことをお勧めします。これにより、マクロをよく知らない読者は、これを見るたびに大きな「WTF」を得ることができます。一般に受け入れられている規則よりも「新しい規則」を発明する場合、実際の必要なしにコードは読みやすくなりません。

これを使用する->どこでもうるさくていです

それは、おそらくあなたがキーワードme（Visual Basic、私は推測する？）を使用して言語で多くのプログラミングをしたために、あなたにそう見えるかもしれません。しかし実際には、それに慣れるだけの問題です- this->かなり短く、経験豊富なC ++プログラマのほとんどがあなたの意見に同意しないと思います。また、上記の場合、使用も使用も適切this->でmeはありません。メンバー関数内のデータメンバーにアクセスするときにこれらのキーワードを除外することで、ごちゃごちゃになりません。

プライベートメンバー変数をローカル変数と区別したい場合はm_、接頭辞として何かのリンクを追加するか、接尾辞として下線を追加します（ただし、ここでわかるように、この規則でも多くの人にとって「うるさい」です）。

しないでください！入力を節約するためにマクロがいたるところにある大規模なコードベースに対処しようとしています。私にこれを再定義することの悪い点は、これがスコープ内にない/適用されない場合でも、プリプロセッサがそれをどこでも置換することです。たとえば、スタンドアロン関数の場合、同僚は私と呼ばれるローカル変数を他のどこかに持っている可能性があります。 。（s）彼はデバッグに満足できません...すべてのスコープで使用できないマクロを持つことになります。

いや！

誰かがあなたのトリックを知らずにそのヘッダーを#includeし、ファイル内のどこかに「me」と呼ばれる変数または関数がある場合に発生する混乱を想像してください。不可解なエラーメッセージが出力されると、それらは恐ろしく混乱します。