Why some people use "this->" when there is no need?

[malibor]

I see some repositories explicitly make use of this->whatever(); for almost every function call within class.

But just saying whatever(); is enough because you don't need this to invoke polymorphic behavior.

I don't get it beyond maybe those guys either have issues invoking member list in their IDE, or they just like to use this pointer for fun?

[lastchance]

maybe those guys either have issues invoking member list in their IDE

Some of us don't use an IDE.

If it's a big class, whose declarations are in a separate header file, some of us just like to know where to start looking.

[malibor]

hm, does it matter which whatever they are using? polymorphic behavior can't be avoided except with static call ClassName::whatever()

I guess the lack of this in function call implies for the reader that this function is not virtual, but there is no warranty the author didn't forget to call it trough this explicitly for code style consistency.

You know exactly which whatever() the author is using.

Makes sense, but isn't IDE supposed to tell you that by just hovering your mouse over function? and it should say ClassName::whatever() for both virtuals and non virtuals.

[malibor]

Some of us don't use an IDE.

Ah this explains why!

[lastchance]

Well, let's suppose that there is a class function named whatever() and there is a function whatever() also defined elsewhere.

In this case it is irrelevant whether you use this-> or not from a member function of the class: it will use the class version.

But now suppose that you do some code development and you decide to rename your class function to whyNot(). The call without the this-> will still be valid code ... but it will call the external routine, which was presumably not intended. However, you will get no warning because it is still valid code.

So, use this-> if there is a prospect of you renaming routines in your class and you want to make damn sure that you won't accidentally revert to a routine outside.

[malibor]

Good explanation for a valid case! I didn't think about non class function with same name and then renaming.

those 2 versions of functions should be very similar in behavior so you don't see that something is wrong with execution but OK.

I have set up my IDE so that color of class function is of different color from non class functions, but still that doesn't produce errors as you say.

I stil find it arcane to use this-> everywhere just to avoid such very rare situations.

[keskiverto]

Its a cost analysis: typing some additional characters vs debugging.
Airplanes have life vests even though emergency landing on water is rare.

[helios]

Makes sense, but isn't IDE supposed to tell you that by just hovering your mouse over function?

You say "just" but that's actually a lot more effort than glancing at the code. It's the same reason one might use different styles for MACROS, Classes, and function_names. Yes, the IDE can tell you in a moment what the identifier refers to, but you can make it even faster by encoding the information into the code.

[ne555]

I think that the this->function() version should be taught*, so the students realise that there is an object being passed as a parameter and make use of it.

> either have issues invoking member list in their IDE
this-> should only give you member functions

> I guess the lack of this in function call implies for the reader that this function is not virtual
¿ah?

^*¿taught, teach, teached?

[helios]

*¿taught, teach, teached?

"Taut", obviously.

[malibor]

Yes, the IDE can tell you in a moment what the identifier refers to, but you can make it even faster by encoding the information into the code.

I think that the this->function() version should be taught*, so the students realise that there is an object being passed as a parameter and make use of it.

There are so many things to be written explicitly for easier code reading, as simple as explicitly write long int instead of just int or more advanced explicitly call constructors of base class in member init list (delegating constructors)

The question is how much of being explicit it too much, it boils down to personal preference for sure.

[helios]

long int instead of just int

Well, 'long int' is a synonym of 'long', not of 'int'.

The problem is both of your examples is that they're only helpful if the reader is unfamiliar with the language, not with the codebase. No amount of language lawyering will let you intuit the meaning of foo(); without any additional information.

[Ganado]

If I do use it, I tend to use "this->" (or "this." in other languages) more when there are large inheritance hierarchies, so that it makes me immediately aware that it's a class member (probably of some superclass), and not a free function. But I seldom use it.

[zapshe]

A lot of times people have variables in their function parameters with the same name as a variable in the class itself, and so using this-> becomes the only way to differentiate.

Though I avoid typing that extra bit if I don't need it.

[jonnin]

I use and delete. Its a good way to see what is available from where I am when the IDE will just list it all with a this-> (lists with just that typed).

Huge projects and some naming conventions schemes will lead to the nightmare of two functions of the same name at times. Ironically some of the better naming schemes dictate in such a way that you end up with the same names. This is by intent, so you can guess the name without looking it up, but it also causes clashes. If your code is prone to the problem, use the tool. If you don't need it, it is visual clutter. The one thing I absolutely hate is

void classname::setvar( type var)
{
this->var = var;
}
the this is totally avoidable and worse, the coder intentionally used the same name twice in the same scope.

[helios]

this->var = var;

I confess to do this, and while I understand and even (to a degree) share why you don't like it, I dislike even more thinking up synonyms for identifiers just to avoid name collisions. "Oh, was it 'buffer', 'mem', or 'data'?" "Was it push(), enqueue(), or append()?" /*this->*/size = length;

[jonnin]

I just add something to the parameter to mark it, like _in
var = var_in;

[zapshe]

I sometimes have something like this:

class T
{
    int size;
    int pos;
    string name;

    T(int a, int b, string c)
    {
         size = a;
         pos = b;
         name = c;
    }

};

Where the parameters are just alphabetical and correspond to the order of the variables as they're written in the class.


I really hate it when the parameters have the same names as the variables in the class! this->var = var is just something I never wanna see.

[helios]

Where the parameters are just alphabetical and correspond to the order of the variables as they're written in the class.

That's terrible. I'd never guess that. If you're doing that you may as well just use random words for names.

T(int beeblebrox, int guess, string taco)

There, that conveys about as much information.

[zapshe]

Well, there's lots of ways to do it. Would be easier to know that if you numbered them instead:

T(int one, int two, string three)