this-> to reference everything

Question

I've recently spent a lot of time with javascript and am now coming back to C++. When I'm accessing a class member from a method I feed inclined to prefix it with this->.

class Foo {

  int _bar;

public:  
  /* ... */

  void setBar(int bar) {
    this->_bar = bar;
    // as opposed to
    _bar = bar;
  }
}

On reading, it saves me a brain cycle when trying to figure out where it's coming from.
Are there any reasons I shouldn't do this?

Answer 1

Using this-> for class variables is perfectly acceptable.

However, don't start identifiers with an underscore, or include any identifiers with double underscore __ anywhere. There are some classes of reserved symbols that are easy to hit if you violate either of these two rules of thumb. (In particular, _IdentifierStartingWithACapital is reserved by the standard for compilers).

Answer 2

In principle, accessing members via this-> is a coding style that can help in making things clearer, but it seems to be a matter of taste.

However, you also seem to use prefixing members with _ (underscore). I would say that is too much, you should go for either of the two styles.

Answer 3

Are there any reasons I shouldn't do this?

Yes, there is a reason why you shouldn't do this.

Referencing a member variable with this-> is strictly required only when a name has been hidden, such as with:

class Foo
{
public:
    void bang(int val);
    int val;
};

void Foo::bang(int val)
{
    val = val;
}

int main()
{
    Foo foo;
    foo.val = 42;
    foo.bang(84);
    cout << foo.val;

}

The output of this program is 42, not 84, because in bang the member variable has been hidden, and val = val results in a no-op. In this case, this-> is required:

void Foo::bang(int val)
{
    this->val = val;
}

In other cases, using this-> has no effect, so it is not needed.

That, in itself, is not a reason not to use this->. The maintennance of such a program is however a reason not to use this->.

You are using this-> as a means of documentation to specify that the vairable that follows is a member variable. However, to most programmers, that's not what usign this-> actually documents. What using this-> documents is:

There is a name that's been hidden here, so I'm using a special technique to work around that.

Since that's not what you wanted to convey, your documentation is broken.

Instead of using this-> to document that a name is a member variable, use a rational naming scheme consistently where member variables and method parameters can never be the same.

Edit Consider another illustration of the same idea.

Suppose in my codebase, you found this:

int main()
{
    int(*fn)(int) = pingpong;
    (fn)(42);
}

Quite an unusual construct, but being a skilled C++ programmer, you see what's happening here. fn is a pointer-to-function, and being assigned the value of pingpong, whatever that is. And then the function pointed to by pingpong is being called with the singe int value 42. So, wondering why in the world you need such a gizmo, you go looking for pingpong and find this:

static int(*pingpong)(int) = bangbang;

Ok, so what's bangbang?

int bangbang(int val)
{
    cout << val;
    return val+1;
}

"Now, wait a sec. What in the world is going on here? Why do we need to create a pointer-to-function and then call through that? Why not just call the function? Isn't this the same?"

int main()
{
    bangbang(42);
}

Yes, it is the same. The observable effects are the same.

Wondering if that's really all there is too it, you see:

/*  IMPLEMENTATION NOTE
 *
 *  I use pointers-to-function to call free functions
 *  to document the difference between free functions
 *  and member functions.
 */

So the only reason we're using the pointer-to-function is to show that the function being called is a free function and not a member function.

Does that seem like just a "matter of style" to you? Because it seems like insanity to me.

Answer 4

Here you will find:

Unless a class member name is hidden, using the class member name is equivalent to using the class member name with the this pointer and the class member access operator (->).

Answer 5

I think you do this backwards. You want the code to assure you that what happens is exactly what is expected.

Why add extra code to point out that nothing special is happening? Accessing class members in the member functions happen all the time. That's what would be expected. It would be much better to add extra info when it is not the normal things that happen.

In code like this

class Foo
{
 public:
    void setBar(int NewBar) 
    { Bar = NewBar; }

you ask yourself - "Where could the Bar come from?".

As this is a setter in a class, what would it set if not a class member variable?! If it wasn't, then there would be a reason to add a lot of info about what's actually going on here!

Answer 6

Since you are already using a convention to signify that an identifer is a data member (although not one I would recommend), adding this-> is simply redundant in almost all cases.

Answer 7

This is a somewhat subjective question obvously. this-> seems much more python-idiomatic than C++-idiomatic. There are only a handful of cases in C++ where the leading this-> is required, dealing with names in parent template classes. In general if your code is well organized it will be obvious to the reader that it's a member or local variable (globals should just be avoided), and reducing the amount to be read may reduce complexity. Additionally you can use an optional style (I like trailing _) to indicate member variables.

Answer 8

It doesn't actually harm anything, but programmers experienced with OO will see it and find it odd. It's similarly surprising to see "yoda conditionals," ie if (0 == x).