I'm trying to understand member shadowing in inheritance.

Consider this code with inheritance where both classes have a public data member named x.

class A {
    public:
        int x;
};

class B : public A {
    public:
        int x; 
};

int main(void)
{
    B test;
    return 0;
}

When I compile this with : c++ -Wshadow file.cpp I don't get any warnings. This confuses me because my understanding is that shadowing occurs when an inner scope declares a name that's already declared in an outer scope.

In this case, B::x seems to be shadowing A::x, and the shadowing is real because to access A::x in B, I would need to use scope resolution: test.A::x

What am I missing about how -Wshadow works with inheritance? Is this not considered shadowing, or is there something special about member variables in inheritance?

I'm trying to understand member shadowing in inheritance.

Consider this code with inheritance where both classes have a public data member named x.

class A {
    public:
        int x;
};

class B : public A {
    public:
        int x; 
};

int main(void)
{
    B test;
    return 0;
}

When I compile this with : c++ -Wshadow file.cpp I don't get any warnings. This confuses me because my understanding is that shadowing occurs when an inner scope declares a name that's already declared in an outer scope.

In this case, B::x seems to be shadowing A::x, and the shadowing is real because to access A::x in B, I would need to use scope resolution: test.A::x

What am I missing about how -Wshadow works with inheritance? Is this not considered shadowing, or is there something special about member variables in inheritance?

• c++
• oop
• inheritance
• g++
• shadowing

• 2 This is opinion-based, since any settings related to compiler warnings are discretionary (quality of implementation concerns, about which the C++ standard says nothing) and work in a way that the implementers of that compiler decide. AFAIK, none of us can read the minds of anyone, including compiler developers – Peter Commented Jan 21 at 12:26
• Aah I see, so my understanding is not wrong then, because I thought that maybe my understanding of shadowing is not fully correct or that I'm missing something. thanks for the clarification tho – Anas Jawad Commented Jan 21 at 13:01
• @Peter This is a question, not an opinion. The reason is conformation to the C++ Standard. – Rud48 Commented Jan 21 at 14:40
• @Rud48 the "why" in the title is opinion-based. Though, basing it on opinions requires to know that there is no other reason, and thats what the actual question (and answer) is about. Imho there is no need to close this – 463035818_is_not_an_ai Commented Jan 21 at 14:54
• 2 "Shadowing" is not a technical term defined by the C++ standard; it means whatever a compiler-writer or a commentator thinks it means. – Pete Becker Commented Jan 21 at 15:17

1 Answer 1

-Wshadow warns about local variables:

Warn whenever a local variable or type declaration shadows another variable, parameter, type, class member (in C++), or instance variable (in Objective-C) or whenever a built-in function is shadowed. Note that in C++, the compiler warns if a local variable shadows an explicit typedef, but not if it shadows a struct/class/enum. If this warning is enabled, it includes also all instances of local shadowing. This means that -Wno-shadow=local and -Wno-shadow=compatible-local are ignored when -Wshadow is used. Same as -Wshadow=global.

For example:

class A {
    public:
        int x = 0;
};

class B : public A { 
    void foo() {
        int x;  // warning: declaration of 'x' shadows a member of 'B'
    }    
};

In your example x is not a local variable.

The documentation does not mention warning about member variables that shadow a member from a base.

There is no deeper reason to this other than this is how GCC implements the warning. Note that e.g., Clang does also not warn for my example (see here).