On 01/06/2010 22:13, Ian Lance Taylor wrote:
>> * When a method refers to a non-static data member, it should always
>> qualify the reference with this->.
>>
>> I'm very opposed to this. To me, it makes the code less readable
>> because it lets the author write code that's hard to understand at a
>> larger scope. I would forbid explicit references to "this" except to
>> pass it unadorned as a parameter to some other function. If it's not
>> clear where method call data comes from, write clearer code!
>>
>> If you're implementing a class, it should be clear you're implementing a
>> class, and implied that data/methods come from the class unless
>> specified otherwise (which you'd have to do anyway, like foo->reg_p()).
>> If it's not clear, you've not properly encapsulated the class and you
>> need to redesign it so it *is* properly contained and easy to
>> understand.
>> DJ never refers to himself in the third person, I don't see why his code
>> should.
>
> Our current code always uses the equivalent of an explicit this
> pointer, except that it is called something else. Therefore I would
> argue that this is not new. I don't see why using an explicit this->
> makes code harder to understand in a larger scope; the explicit this->
> makes it very clear where data is coming from.
>
> The biggest need for this-> is when calling methods in the current
> class if the current class happens to be in a template. The C++
> template namespace lookup rules are confusing. The explicit this->
> makes them clear. While it's true that most code is not in a
> template, it's possible that a template will be added later.
>
> I'm not going to fight to the death on this one, and I would be
> interested in hearing other opinions. I've been using explicit this->
> in my own C++ code for many years, and I find that it clarifies rather
> than confuses.
In a project with as many globals as we have, it's kinda handy to know at a
glance whether a member function is accessing a data member or a global. But
if we follow the data-members-must-end-with-an-underscore convention, that
would convey the same information. So I'd be happy with either one of those
two, and using both would seem overkill.
cheers,
DaveK
