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