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 thisin 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.
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 towhyNot(). 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.
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.
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.
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.
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.
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.
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;