Re: [boost] Warning policy? local variable hides (i.e. shadows) global variable

Subject: Re: [boost] Warning policy? local variable hides (i.e. shadows) global variable
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-01-19 01:04:57

On 19/01/2015 05:52, Olaf van der Spek wrote:
> Sure, but using a prefix or suffix for member variables is a common
> practice. Do you not do it?

Just a reminder that the issue originally being discussed here is where 
USER CODE has declared a global variable:

   std::string message;

and LIBRARY CODE has declared a method:

   namespace boost
   {
       namespace skywriting
       {
            class marquee
            {
            public:
                void set_message(const std::string& message)
                {
                   // generates warning because local "message"
                   // hides global "message"
                   ...
                }
            };
       }
   }

This is obviously the compiler being overly pedantic, but the choices 
seem to be between:

   1. Doing nothing, and let the user pick "better" names for their 
global variables if the warnings offend them (some have suggested using 
a g_ prefix, but of course the user can do whatever they like).  (This 
may annoy some users who have pedantic warnings on but don't want to 
"fix" this themselves.)

   2. If compiler support exists, disable raising the warning while 
Boost code is being compiled.  (This may hide genuine bugs in Boost that 
may otherwise be detected when compiling unit tests.)

   3. Adopting some weird-and-unlikely-to-collide-with-user naming 
convention for parameters and other local variables of inline methods. 
(This will uglify Boost code.)

Personally, I would strongly lean towards #1, with the caveat that 
whatever patterns did lead to discovery of real bugs should probably be 
identified so they can be acted on.

I also wonder if proper precompiled module support would solve this, as 
that would be a big hint to the compiler that the symbols aren't meant 
to interact when they're from different modules.