Есть ли причина использовать это->

Ответ 1

Чтобы гарантировать, что вы запускаете ошибки компилятора, если есть макрос, который может быть определен с тем же именем, что и ваша функция-член, и вы не уверены, что он надежно undefined.

Не шучу, я почти уверен, что мне пришлось делать именно это по этой причине!

Ответ 2

Единственное место, где это действительно имеет значение, - это шаблоны в производных классах:

template<typename T>
class A {
protected:
  T x;
};

template<typename T>
class B : A<T> {
public:
  T get() {
    return this->x;
  }
};

Из-за деталей в поиске имен в компиляторах на С++, должно быть ясно указано, что x является (унаследованным) членом класса, наиболее легко выполняемый с помощью this->x. Но это довольно эзотерический случай, если у вас нет шаблонных иерархий классов, вам не нужно явно использовать this для доступа к членам класса.

Ответ 3

Если в той же области с одним и тем же именем есть другая переменная, это- > устранит двусмысленность.

void Bar::setFoo(int foo)
{
    this->foo = foo;
}

Также он дает понять, что вы ссылаетесь на переменную-член/функцию.

Ответ 4

Как "причина кода", чтобы отличить локальный параметр или значение (которое имеет преимущество) от члена:

class Foo
{
    int member;
    void SetMember(int member)
    {
       this->member = member;
    }
}

Однако это плохое начало для начала и обычно можно решить локально.

Вторая причина - более "среда": иногда помогает Intellisense фильтровать то, что я действительно ищу. Тем не менее, я тоже, когда я использую это, чтобы найти участника, которого я ищу, должен также удалить это.

Так что да, есть веские причины, но они все временные (и плохое в долгосрочной перспективе).

Ответ 5

Я могу думать о читабельности, например, когда вы используете дополнительные круглые скобки, чтобы все было ясно.

Ответ 6

Я думаю, что это в основном как помощь читателю. Это делает его явным, что то, что называется, является методом объекта, а не обычной функцией. При чтении кода может быть полезно знать, что вызываемая функция может, например, изменять поля в текущем объекте.

Ответ 7

Это действительно вопрос стиля и применяется ко многим другим языкам, таким как Java и С#. Некоторые люди предпочитают видеть явные this (или self, или Me, или что-то еще), а другие нет. Просто пойдите с тем, что находится в ваших руководящих принципах стиля, и если это ваш проект, вы получите решение о рекомендациях.

Ответ 8

Это задано пару раз, но его трудно найти, потому что "this" кажется, что слово stop для поиска.

Вот мой собственный вопрос: Есть ли какие-либо причины не использовать "his" ( "Self" , "Me" ,...)?

Ответ 9

Это делается для того, чтобы быть явным о том, что используемая переменная является переменной-членом, а не локальной или глобальной переменной. Это не обязательно в большинстве случаев, но явное описание области может быть полезно, если вы перетащили переменную с объявлением с тем же именем в более узкой области.

В компаниях, над которыми я работал, мы просто добавили переменные "m_" к переменным-членам. Иногда это может быть полезно, и я предпочитаю использовать "this → ".

Изменить: Добавив ссылку на документы GCC, в которых объясняется случай, когда использование this- > необходимо для правильной работы независимого поиска.

Ответ 10

Я не думаю, что это имеет значение для компилятора, но я всегда пишу this- > , потому что считаю, что он делает самообъявление кода.

Ответ 11

Несознание: в случае, если у вас есть другая аналогичная функция/переменная имени в том же пространстве имен? Я никогда не видел использования по какой-либо другой причине.

Ответ 12

Это ваш собственный выбор. Я нахожу это более понятным, когда вы используете это. Но если вам это не нравится, вы можете опустить его.

Ответ 13

Я предпочитаю его без явного указателя. Для вызовов методов это не добавляет большого значения, но помогает отличать локальные переменные от переменных-членов.

Ответ 14

Я не могу вспомнить точные обстоятельства, но я видел (очень редкие) экземпляры, где мне приходилось писать "this- > membername", чтобы успешно скомпилировать код с GCC. Все, что я помню, это то, что это не связано с двусмысленностью, и поэтому потребовалось некоторое время, чтобы выяснить решение. Тот же код скомпилирован без использования this- > в Visual Studio.

Ответ 15

Другой случай, который появился на сцене после С++ 11, находится в lambdas, где зафиксировано this.

У вас может быть что-то вроде:

class Example
{
  int x;
public:
  std::function<void()> getIncrementor()
  {
    return [this] () -> void
    {
      ++(this->x);
    }
  }
};

Хотя ваша лямбда создается внутри класса, она будет иметь доступ только к локальным переменным, захватив их (если ваш компилятор выполнит С++ 14) или захватит this. Во втором случае внутри тела лямбда просто нет x, но только this->x.

Ответ 16

Я буду использовать его для вызова операторов неявно (типы возвращаемых и типов ниже - это просто манекены для составления кода).

struct F {
  void operator[](int); 
  void operator()();

  void f() {
    (*this)[n];
    (*this)();
  }

  void g() {
    operator[](n);
    operator()();
  }
};

Мне больше нравится синтаксис *this. Он имеет немного другую семантику, поскольку использование *this не будет скрывать не-членные функции оператора с тем же именем, что и элемент.

Ответ 17

Есть много хороших ответов, но ни один из них не упоминает, что использование этого- > в исходном коде облегчает чтение, особенно когда вы читаете код некоторой длинной функции, но даже короткую функцию, представьте код:

bool Class::Foo()
{
    return SomeValue;
}

от просмотра этого кода вы не можете точно знать, что такое SomeValue. Это может быть даже некоторая #define или статическая переменная, но если вы пишете

bool Class::Foo()
{
    return this->SomeValue;
}

вы четко знаете, что SomeValue является нестатической переменной-членом того же класса.

Таким образом, это не просто поможет вам гарантировать, что имя ваших функций или переменных не будет конфликтовать с некоторыми другими именами, но это также облегчает другим читать и понимать исходный код, записывая источник самодокументирования Иногда код также очень важен.