Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk