LWN.net Logo

Shadowing a class member: wrong?

Shadowing a class member: wrong?

Posted Jan 29, 2010 16:35 UTC (Fri) by giraffedata (subscriber, #1954)
In reply to: LCA: Static analysis with GCC plugins by iabervon
Parent article: LCA: Static analysis with GCC plugins

I'd say an even more basic goal is to provide the coder with tools to assist in his personal coding style. If you like to use local variables that shadow class members, fine. Don't turn on this checker. But if you avoid that because you find you do it wrong too often, turn on the checker.

Personally, I wouldn't use this, but would really like to see a checker that catches every time I refer to a class member implicitly (i.e. without "this->". To prevent confusion about what is a class member and what is local, I observe a discipline of always referring to the former with this->, but get burned sometimes when I neglect to define a local variable and implicitly get a class member instead.


(Log in to post comments)

Shadowing a class member: wrong?

Posted Jan 29, 2010 17:55 UTC (Fri) by iabervon (subscriber, #722) [Link]

Obviously, it has to be on a project scale instead of an individual scale; it doesn't help if you never make a mistake based on a variable shadowing, if it's not common in a particular project and other people make mistakes because of that code.

In general, it's probably best to either always use "this->" or never use it (and never shadow members) within a given codebase. Either way works, but any mixture leads to patches which can't be reviewed easily (that is, you can't tell from the function header and 3 lines of context whether a patch is right).

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds