13 Jul, 2010, JohnnyStarr wrote in the 1st comment:
Votes: 0
It makes sense to me that if an object needed to pass itself to an outside function, it would send "this".
I've seen some C++ that uses "this" anytime it accesses a property. Does that protect the author from some
sort of folly?

An example might be:

void Character::getObject(Object * obj)
{
obj->next_content = this->carrying;
this->carrying = obj;
obj->carried_by = this;
obj->in_room = NULL;
obj->in_obj = NULL;
this->carry_number += get_obj_number(obj);
this->carry_weight += get_obj_weight(obj);
}

// VS.

void Character::getObject(Object * obj)
{
obj->next_content = carrying;
carrying = obj;
obj->carried_by = this;
obj->in_room = NULL;
obj->in_obj = NULL;
carry_number += get_obj_number(obj);
carry_weight += get_obj_weight(obj);
}
13 Jul, 2010, kiasyn wrote in the 2nd comment:
Votes: 0
if you make a local variable called carry_number or carry_weight then you use that it will assign the value to the local variable rather than the member of the object, unless you explicitly declare this->
13 Jul, 2010, Kline wrote in the 3rd comment:
Votes: 0
Would enabling shadow variable in warnings prevent that? I've used / omitted this-> for my own readability's sake in various places but never gave consideration about a local variable named something in the member class (and haven't had that problem; yet).
14 Jul, 2010, kiasyn wrote in the 4th comment:
Votes: 0
I think it does… not sure.
14 Jul, 2010, Kaz wrote in the 5th comment:
Votes: 0
JohnnyStarr said:
It makes sense to me that if an object needed to pass itself to an outside function, it would send "this".
I've seen some C++ that uses "this" anytime it accesses a property. Does that protect the author from some
sort of folly?


For the most part, it's a stylistic thing. I find it "noisy", personally. The only time it's actually necessary is when your code is looking at a member variable for a class template who inherited from one of its template parameters. For example:

template <class Base>
struct Derived : Base
{
Derived()
{
// Without "this->", the compiler must assume that foo_ is
// a non-member variable, because it can't see it in the current
// scope during that compilation stage. With this->, it now knows
// that it is a member variable from the inherited base class.
this->foo_ = true;
}
};
14 Jul, 2010, David Haley wrote in the 6th comment:
Votes: 0
Kaz said:
The only time it's actually necessary is when your code is looking at a member variable for a class template who inherited from one of its template parameters.

Or when there is shadowing, as was mentioned.

void Foo::bar(int x) {
this->x = x;
}


I usually just use a naming convention that avoids the problem, by adding a _ suffix to member variables. Some people hate that, though, and some people hate using 'this'. :shrug:
14 Jul, 2010, Kaz wrote in the 7th comment:
Votes: 0
David Haley said:
Kaz said:
The only time it's actually necessary is when your code is looking at a member variable for a class template who inherited from one of its template parameters.

Or when there is shadowing, as was mentioned.


At which time you can also change the names of the variables involved in order to avoid the this->. You can't do that with the case I showed.

Incidentally, I also add an underscore suffix. However, if I were a regular Visual Studio person, however, I'd probably use the time-honoured m_ as it plays more nicely with Intellisense.
14 Jul, 2010, David Haley wrote in the 8th comment:
Votes: 0
Quote
At which time you can also change the names of the variables involved in order to avoid the this->. You can't do that with the case I showed.

Sure, that's true. But if you change names, you start running into somewhat silly cases like:

void Foo::bar(int otherX) {
x = otherX;
}


or 'aX', 'theX', 'newX', etc. My preference is to leave variable names as clear as possible, and use 'this' to disambiguate.
0.0/8