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.