В каждом проекте свои стандарты. Выберите свой, в чем проблема?
А по сабжу, я юзаю this для доступа, так читабильнее имхо.

int cl::var = 0;
void cl::foo(int var)
{
   this->var = var;
}

Больше применения не вижу.

Приписывай буковку m например, если для себя пишешь, а если не для себя какой нафик холивар, бери больше, тащи дальше.

Имеется ввиду не к мемберам обращение, а к методам.

Зачем писать то, что писать не надо и что никак не помогает?
Если вдруг это очень важно, то методы можешь выделять, скажем, подчёркиванием вначале. Или букву какую добавляй.

Сам не употребляю и смысла большого не вижу.

Страуструп, кажется, пишет в «специальном издании», что эти два случая (писать и не писать) приведут к идентичному скомпилированному коду.

еще для шаблонов

template <typename T>
struct A {
    T member_;
    T &get(  ) { return member_; }
};


template <typename T>
struct B: public A<T> {
    void print(  ) {
        std::cout << this->get( ) << "\n"; // тут, либо A<T>::get( )
    }
};

int main( int argc, const char **argv )
{

    B<int> t;
    t.member_ = 1000;
    t.print( );

    return 0;
}

Этот вопрос не является независимым от других аспектов codestyle. Codestyle следует рассматривать в целом.

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

В С++ хоть можно написать cl::var = var; вот в жабе в подобном случае this. действительно нужен.

Автор темы спрашивал про стиль, а не про реализацию.

С чего ты взял?

нужно или нет

зависит от «кому»

Использую только в случае, если какая-либо локальная переменная или аргумент функции имеет такое же имя, как вызываемая функция-член. А вообще мне даже нравится большая явность, которая получается при использовании this. В некоторых языках вообще нельзя обратиться к собственным переменным/методам без использования self, и ничего, живут люди.

::bar();

нашёл где спросить... здесь программисты в красную книгу занесены

шаблоны же, ну

... и только загромождает кот.

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

хотите - пишите, хотите - нет. на мой взгляд лучше this-> чем m_ и все остальное.

Без ::, без this-> унаследованная bar не видна.

Плюсую

Чтобы раз и навсегда снять проблему разборок «тупоконечников с остроконечниками», выеденного яйца внатуре не стоящую, придумали гайдлайны, которые могут кому-то не нравиться, но он может идти на... другой проект. Кто-то главный на проекте должен бросить монетку и сказать «хорек и никаких сусликов». Если такого нету - это не проект, а кружок анархистов.

Для особо непонятливых (бывают упоротые с ценным мнением) гайдлайны можно зафорсить утилитами проверки типа cppcheck на билдсервере - с условием начала сборки только после успешного прохождения проверки.

А, вот вспомнил, где видел.

The code generated by the compiler is exactly the same, so you don’t need to use this in such a fashion; occasionally, you’ll see code where people explicitly use this-> everywhere but it doesn’t add anything to the meaning of the code and often indicates an inexperienced programmer

(c) Thinking in C++, Volume 1, 2nd Edition Completed January 13, 2000 Bruce Eckel, President, MindView, Inc.

для особо непонятливых

бывают случаи, когда использование this необходимо

В интернетах не нашел хорошего холивара по данной теме

Так тебе холивар нужен или аргументированный ответ?

Лично я this-> пишу только если есть опасность путаницы. В остальных случаях не вижу смысла загромождать код.

А так - тебе правильно ответили, в каждом проекте свой стиль, его и надо придерживаться.

Использую this, когда один из аргументов метода называется that или other, или когда рядом есть однотипные сущности (типа otherWindowGeometry, тогда логично будет напиписать this->geometry()).

Сам не употребляю, большинство колег тоже, но пару раз вступал на грабли с перегруженными свободными функциями(ситуация, когда внезапно появился метод с внешне такой жи сигнатурой, и ты это прощёлкал). Имхо это ССЗБ, по крайней мере, лично меня, это не заставило таки юзать сей синтаксис.

Предпочитаю делать вызов методов через указатель this. Ибо это максимально наглядно показывает обращение к методу, а не, скажем, к глобальной функции, что важно. Код должен быть максимально нагляден и исключать если возможно любые вопросы о выполняемом действии. В моей IDE сие даёт удобную автодополняшку, что не важно, но приятно и удобно.

И? Как и в случае с бездумным использованием dynamic_cast эти случаи чаще всего говорят о ранее допущенном архитектурном факапе («enjoy your multiple inheritance» (с)), когда нужно выбрать из образовавшейся виртуальной каши нужный метод, который естественным путем (без this) не выбирается. Т.е. ССЗБ и необходимо «поправить в консерватории».

за использования this в С++, где не попадя, надо жестоко пиздить!