What is this fad of people using 'this->member' all over the place instead of just referring to members the normal way? It makes my teeth itch.

It's easier to use intelisense with.

True, but there are also a few minor side effects.

First is that if the class overrides operator-> it will use that instead. This is a fairly rare thing, but something to consider.

Second is that it has the potential to cause some unnecessary trips to memory. Most optimizers will strip that away, but as this is the "General Programming" forum rather than "For Beginners", we should not be over-reliant on the optimizer. I've worked on several systems over the years (Nintendo DS, PalmOS, etc.) that when encountered would dereference the this pointer and follow it rather than use the information already loaded in registers.


My current studio includes it is in our programming style guide as a restricted practice. I flag it in code reviews as an error when I see it.

As pointed out above, overriding -> has no effect on this.

That is what makes it confusing, and one of the reasons to avoid it.

The arrow operator is not overriden very often, but it is one of those "gotcha" areas of C++. It generally works the way programmers expect it to work, but there is some subtlety in the drill-down behavior when operator overloading is involved.

Contrived example to demonstrate:

#include <iostream>
 
struct Concrete {
    void foo() { std::cout << "Concrete::foo\n"; }
};
struct Proxy {
    Concrete *a;
    void foo() { std::cout << "Proxy::foo\n"; }
    Concrete* operator->() { return a; }
};
struct Proxy2 {
    Proxy *b;
    void foo() { std::cout << "Proxy2::foo\n"; }
    Proxy& operator->() { return *b; }
 
    void RunFoo() {
        foo(); // Calls Proxy2::foo
        this->foo();  // QUIZ #1:  Which foo() is called?
        (*this).operator->()->foo(); // QUIZ #2: Which foo() is called?
    }
};
int main()
{
    Concrete a;
    Proxy b = { &a };
    Proxy2 c = { &b };
    c.RunFoo();
    c->foo(); // QUIZ #3: Which foo() is called?
}

The answers are not surprising at all when you stop to think about them.

The problem is that you need to stop and think about them.

I guess you could say that the distinction between (*this)->foo() and this->foo() may be easily overlooked, but (*this)->foo() is strange looking enough to warrant special attention. Similarly with (*this).operator->()->foo(), except I don't see why you would ever use that instead of (*this)->foo().

I don't know, maybe whenever you want to intentionally make something confusing to try to prove a point.

And yet the fact that operator-> is automatically called recursively until it returns an actual pointer type is occasionally used to implement special behavior or convenient helper functions by using wrapper objects that implement it. It's often the easiest way to keep the calling code clean and blissfully ignorant of implementation details. Try implementing a special proxy on top of a basic proxy to some generic object without exploiting operator->.

Basically, the question is: what happened to old-fashioned ways to mark members like 'mMember' or 'member_' that don't have the potential for obscure side effects?

There is no ambiguity for functions either, as a function is either a member, global or called through some other object. Global functions should be in a namespace and "using namespace everything" is often preferring laziness over clear code. So suddenly foo() is obviously a member function, as otherwise it would be something like std::foo() or ::foo().

The point is not that it causes ambiguity or strange behavior.

The point is that it makes the programmer stop for a moment to figure it out.

Code should be obvious. You should generally be able to tell at a glance what the code does. Code that does something tricky should include a great big comment block explaining why it does what it does, the reason the programmer decided to take the less obvious route, and instructions for future developers who maintain it.

When I see "this->foo()" my brain needs to pause, if only for a moment, and ask why they are calling a function from the object rather than calling the function directly.

Just the fact that my brain must switch gears for a moment, no matter how small that moment is, that is the issue.

I already know that it's pointless and that it's annoying as hell. I'm just wondering where it came from.

Did people really start doing this just for intellisense? I mean JFC, just upgrade to 2012.

The point is not that it causes ambiguity or strange behavior.

Your original point was that it causes side effects. Are side effects not ambiguity or strange behavior?