-Wshadow option vs. init lists

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(using GCC 6.2 on a GNU/Linux system)

I'd love to enable -Wshadow, but unfortunately it gets upset with an
extremely common idiom in our entire codebase (and lots of other places
I've worked):

   class Foo
   {
       int foo;
   public:
       Foo(int foo) : foo(foo) {}
   };

Here it's very clear what we want and the standard requires that it will
behave as expected.  IMO, this is not appropriate to warn about.
I can envision more complex initializer lists where things could get
confusing, if other initializers used the "foo" parameter as well, but
this one is what is used almost all the time and it's obviously fine.

This issue keeps us from being able to use -Wshadow generally, but
whenever I do turn it on and trudge through the output (or some small
subset of the output, before I get tired...) I find code which may not
be buggy, but is definitely questionable.  I'd love to fix the real
issues and leave this warning on full-time.

Clang has an additional warning flag, -Wshadow-field-in-constructor. 
There, it's not enabled by default with -Wshadow but even if it were in
GCC and I was able to add -Wno-shadow-field-in-constructor I would be
happy.

What do people think about making a special case for -Wshadow, either
that it will never warn for this specific situation (where the parameter
is used to initialize a member variable of the same name, which would
cover 90% of my cases) or adding a new option to turn off warnings like
this in constructor parameters completely, like clang does?

I wrote a patch for this, but it just forcibly disables this check
always for ctor parameters, there's no command-line configuration for
it.



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux