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: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-01-19 02:44:21

Le 15/01/15 14:11, Beman Dawes a écrit :
> GCC and Clang have had a warning for years (-Wshadow): "Warn whenever
> a local variable or type declaration shadows another variable,
> parameter, type, class member (in C++), or instance variable (in
> Objective-C) or whenever a built-in function is shadowed. Note that in
> C++, the compiler warns if a local variable shadows an explicit
> typedef, but not if it shadows a struct/class/enum."
>
> VC++ 2015 (aka 14.0) Preview has now added a similar warning, C4459.
> For example, "c:\boost\modular\develop\boost\lexical_cast\detail\converter_lexical_streams.hpp(429):
> warning C4459: declaration of 'n' hides global declaration". The VC++
> warning also provides location info so is easy to view both the
> declarations involved. In this case, the declaration "bool
> operator<<(short n)" is shadowing a variable name in the unnamed
> namespace of the calling translation unit.
>
> The process of clearing these shadow warnings occasionally finds bugs
> that are otherwise difficult to detect. Peter Dimov and I have both
> found bugs in our code in the process of clearing the new C4459
> warning. Even though most of the warnings don't actually signify bugs,
> I'm finding that clearing them makes code clearer and less confusing,
> particularly code I haven't looked at in a long while.
>
> Should Boost have policy to clear these warnings?
>
> A lot of the warnings involve function argument names. Should we have
> a guideline to prevent shadow warnings?  A convention for argument
> names would make it easier to submit pull requests. Possible
> guidelines:
>
> * Prefix function argument names with "a_". Rationale: The "m_" prefix
> for member names has been a success.
> * Suffix function argument names with "_". Rationale: Short and less
> distracting than "m_" prefix.
>
Hi,

Boost is a set of libraries without coding style guidelines. Each author 
has its own rules/guidelines. What is desirable is that at least each 
source is coherent.

I will suggest that each library add in its documentation if it adheres 
to the no-shadow warnings and if it adheres, how the author want the 
patches?

A global page could be written to this purpose and each library could 
reference this page and its approach respect to this guidelines.

Best,
Vicente