"#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->. 그러나 #define me (*this)좋은 C ++ 연습으로 간주 될 수 있습니까? me매크로에 실용적인 문제가 있습니까? 그리고 C ++ 프로그래머로서 me매크로를 사용하는 일부 코드의 독자가 된다면 그것을 원하십니까?

편집 : 많은 사람들이을 사용하여 구체적으로 대조를 주장하지는 me않지만 일반적으로 이것을 명시 적으로 대조합니다. "이 곳 어디에서나 명시 적"의 이점이 무엇인지 명확하지 않을 수 있습니다.

"이 곳 어디에서나 명시 적"의 이점은 무엇입니까?

• 코드의 독자로서 당신은 무엇을 액세스했는지 확실하게 알고 있으며, 먼 코드에서 확인과는 다른 것에 집중할 수 있습니다.
• 보다 구체적으로 검색 기능을 사용할 수 있습니다. "검색 this->x"만 검색보다 더 많은 원하는 결과를 얻을 수 있습니다 " x"
• 일부 멤버를 삭제하거나 이름을 바꾸는 경우 컴파일러는이 멤버가 사용되는 위치를 확실하게 알려줍니다. (일부 전역 함수는 동일한 이름을 가질 수 있으며 명시 적으로 사용하지 않으면 오류가 발생할 수 있습니다.)
• 코드를 리팩토링하고 멤버에서 멤버가 아닌 함수를 명시 적으로 만들 때 (더 나은 캡슐화를 위해) 이것은 편집해야하는 위치를 나타내며이를 멤버가 아닌 함수 매개 변수로 제공된 클래스의 인스턴스에 대한 포인터로 쉽게 바꿀 수 있습니다.
• 일반적으로 코드를 변경하는 경우 명시 적으로 이것을 사용하지 않을 때 어디서나 명시 적으로 사용하는 경우보다 오류가 발생할 가능성이 더 큽니다.
• 명시 적으로 이것은 외부에서 object.membervs. 멤버를 액세스 할 때 명시 적 "m_"보다 덜 시끄 럽습니다 ( object.m_member이 지점을 발견하기 위해 @Kaz 덕분에)
• 명시 적으로 이것은 모든 멤버 (속성 및 메소드)에 대한 보편적 문제를 해결하는 반면, "m_"또는 다른 접두어는 속성에만 실용적으로 사용할 수 있습니다.

이 목록을 다듬고 확장하고 다른 장점과 사용 사례를 알고 있다면 어디에서나 명시 적으로 알려주십시오 .

전혀 그렇지 않다.

녹색 목초지로 떠난 후 몇 년이 지난 지금부터 코드를 유지할 프로그래머를 염두에두고 사용하는 언어의 일반적인 규칙을 따르십시오. 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_접두사로 링크 를 추가 하거나 접미사로 밑줄을 추가 하십시오 (그러나 여기 에서 볼 수 있듯이이 규칙은 많은 사람들에게 너무 시끄 럽습니다).

제발 하지마! 매크로를 사용하여 입력을 저장하는 큰 코드베이스에 대처하려고합니다. 이것을 나에게 다시 정의 할 때의 나쁜 점은 프리 프로세서가 범위에 있지 않거나 적용되지 않는 곳, 예를 들어 독립형 함수 인 경우에도 어디서나 그것을 대체 할 수 있다는 것입니다. 동료의 동료는 다른 곳에 나라는 로컬 변수가있을 수 있습니다. 그는 디버깅에 만족하지 않을 것입니다 ... 모든 범위에서 사용할 수없는 매크로가 생깁니다.

아니!

누군가 #include가 해당 헤더를 가지고 있고, 당신의 트릭을 알지 못하고, 파일의 다른 곳에 "me"라는 변수 나 함수가있는 경우 발생할 혼란을 상상해보십시오. 어떤 오류 메시지가 인쇄 될 것인지에 대해 혼란 스러울 것입니다.