Bug 12341 - Request for additional warning for variable shadowing
Summary: Request for additional warning for variable shadowing
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.3.2
: P2 enhancement
Target Milestone: ---
Assignee: Benjamin Priour
Keywords: diagnostic
: 45615 (view as bug list)
Depends on:
Blocks: new-warning, new_warning
  Show dependency treegraph
Reported: 2003-09-19 15:28 UTC by bero
Modified: 2023-04-10 22:58 UTC (History)
8 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2020-05-18 00:00:00


Note You need to log in before you can comment on or make changes to this bug.
Description bero 2003-09-19 15:28:33 UTC
class A { 
        A() { } 
        int aaa; 
class B:public A { 
        B():A() { } 
        int aaa; 
compiles without a warning, and is a potential source of hard to trace problems 
(while it can, of course, be used intentionally). 
It may be useful to give a warning akin to the one given in the case of 
void blah(int a) 
	int a; 
Comment 1 Wolfgang Bangerth 2003-09-19 17:57:14 UTC
Right. Makes sense. 
Comment 2 Hayim Shaul 2005-12-13 09:17:57 UTC
I agree.
I hope this warning will be added in near future versions of g++.
Comment 3 Martin Sebor 2020-05-18 23:43:54 UTC
Reconfirming with GCC 11.0.
Comment 4 Andrew Pinski 2021-10-25 05:10:31 UTC
*** Bug 45615 has been marked as a duplicate of this bug. ***
Comment 5 Eric Gallager 2022-02-04 07:52:14 UTC
is this expected to be a new argument accepted by the `-Wshadow=` flag, or its own separate flag entirely?
Comment 6 Jonathan Wakely 2022-02-04 11:00:09 UTC
This inheritance case is "name hiding" and we have other requests for warnings about it. I think it should be distinct from -Wshadow.
Comment 7 Benjamin Priour 2023-04-07 13:29:36 UTC

I'm currently fixing this, I've put it under -Wshadow for now, as it is still about shadowing names, but I could add a -Wname-hiding or something akin to it.

What about the visibility of the base class field ?

I think that in snippet (1) below, a warning should be issued, as we can imagine Base being virtual with private field x and a friend function foo(Base*) taking polymorphic argument Base*, then Derived inherits of Base, with public field x.
There might be an ambiguity upon accessing x in a call to foo((Base *) derived).

Therefore, I believe the warning should be issued no matter the visibility of the fields within the parent's class.

However, if Grandpa class is privately inherited by Base class, then I'd expect Derived to not issue warnings for its fields named only after Grandpa's.

// Snippet (1)
class Base {
  int x;
class Derived : public Base {
 int x; // issue warning despite Base::x private

// Snippet (2)
class Grandpa;
class Base : private Grandpa;
class Derived : public Base; // No warnings emitted for eponymous fields of Grandpa's