2

Given a structure such as below

class A {
  int test;
  void f() { int test; }
}

I just had a curious case in which the code in f(), when referring to test, compiled under VS2010, correctly referred to the function local variable, however, when compiled under gcc, incorrectly referred to the member variable. Took me quite a while to track down.

Anyway, question is, is there an option in gcc or VS to enable compiler warnings every time a member variable is re-declared in a local function scope?

Cookie
  • 12,004
  • 13
  • 54
  • 83
  • 2
    I'd suggest just not using the same name instead of trying to find a compiler switch. – crashmstr Dec 08 '11 at 14:15
  • @cookie - It is giving you a warning for a reason - i.e. you are inadvertely hiding something. Just change the name! (As an aside you should find the compiler switch to give you as many warnings as possible - the people that wrote the compiler will know more about the ins and outs of the language than you or me) – Ed Heal Dec 08 '11 at 14:19
  • @crashmstr: That is exactly the point. And how would you go about finding all occurrences in the code base? – Cookie Dec 08 '11 at 14:19
  • @cookie - but it is giving you the warning for a reason. – Ed Heal Dec 08 '11 at 14:22
  • @EdHeal: Let me say it again. I am not getting a warning of any sorts – Cookie Dec 08 '11 at 14:22
  • Naming a local the same as either an outer scope variable or a member variable is just terrible programming. It's a bug in gcc, but one that I can easily imagine wasn't found because nobody would do this typically. It's like forcing a reference to change values. Or violating const'ness with casts. You can, but you're asking for it... – Mordachai Dec 08 '11 at 14:31
  • @Mordachai: For such terrible programming, it sure happens a lot in boost. It also goes to tell that -Wshadow isn't included in -Wall. But that isn't the point, here, really, I guess. – Cookie Dec 08 '11 at 14:46
  • @Cookie Boost was written by a lot of different programmers. I haven't spent a ton of time messing around in their source, but I expect that it varies from programmer to programmer. Some folks find flirting with this sort of thing some sort of badge of skill, while I would say it's a badge of foolishness. I can't think of any code that I've ever written that would benefit from intentionally obfuscating the scope of the variables I'm using! – Mordachai Dec 08 '11 at 14:53

2 Answers2

7

In GCC, -Wshadow. From the documentation:

Warn whenever a local variable or type declaration shadows another variable, parameter, type, or class member (in C++), or whenever a built-in function is shadowed. Note that in C++, the compiler will not warn if a local variable shadows a struct/class/enum, but will warn if it shadows an explicit typedef.

Mike Seymour
  • 249,747
  • 28
  • 448
  • 644
3

I don't know if any such option exists.

But if it doesn't exist, then you can do the following. In fact, the naming convention is preferred even if there exists some compiler option to avoid the problem in the question, for it covers broader area of concerns:

class A {
  int m_test;   //use some naming conventions!
  void f() { int test; }
};

That is, use some rules in naming the member variables, such as, prefix each with m_ as in m_test, Or use suffix as in test_. This is the usual approach adopted by many programmers, and in many companies, there is similar rules which they impose when coding.

Such naming conventions not only help avoiding the problem you came across, it also increases readability and maintainability, as the name test suggests nothing as to whether it is local variable or member variable in the absence of naming conventions. But once you adopt some naming conventions, such things become clear.

Nawaz
  • 353,942
  • 115
  • 666
  • 851