Re: [Boost-users] Boost 1.54.0 Header Warnings: Shadowed Variables

Subject: Re: [Boost-users] Boost 1.54.0 Header Warnings: Shadowed Variables
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-11-13 14:14:26

On 13 Nov 2013 at 12:32, Tom Browder wrote:

> > I personally deliberately and intentionally shadow both variable and
> > type names in non-public namespaces where doing so significantly
> > eases my maintenance costs.
> 
> I can't address how shadowing eases your maintenance costs (but I
> would be interested to hear how).

Here you go:
 
https://github.com/BoostGSoC/boost.afio/blob/master/boost/afio/detail/
std_atomic_mutex_chrono.hpp

This technique is not unusual in Boost: mapping C++11 STL facilities 
into a namespace, or if not available then Boost equivalents. AFIO 
code can then use boost::afio::future not caring who implemented it, 
and that is a serious maintenance win.

This of course explicitly makes problematic someone who does using 
namespace boost::afio to map afio's stuff into the local namespace - 
in particular, doing using namespace boost::afio in the global 
namespace will cause the compiler to fail to compile due to symbol 
collision, while mapping afio's namespace into a local namespace also 
containing a map of boost and/or std will cause a compile error at 
the point of ambiguous symbol use. I expect that will come up in peer 
review, and maybe I'll be asked to move these implementation maps 
into a boost::afio::impl_maps namespace or something to prevent 
collision with namespace boost or namespace std. Equally people 
really ought to not map any namespace into the global namespace, it's 
always a bad idea so a compile error is a good thing. And for local 
namespace maps you can resolve ambiguous symbol clashes using the 
using keyword.

> > None of this pollutes any public namespace - I therefore see no
> 
> Well, Niall, I disagree.  Your headers are very much in the user's
> space and any problems are also the user's problems.

The same goes with anyone's code. If my code has a bug, that's a 
problem for the user too. I see no difference between that and any 
shadowing issues if and only if I don't do shadowing in a namespace 
which imposes upon user code. Shadowing ought to be an implementation 
detail and/or technique only. If it has no consequence on user code 
apart from -Wshadow warnings, I see no issue here.

Note I am generally opposed to loop variable shadowing done out of 
laziness, mainly because it makes printing the current variable value 
during debugging hard. That said, I have been known to occasionally 
do so anyway e.g. in macro expansion tricks. And member variable 
shadowing e.g. where you intentionally shadow a this->variable with 
variable is a useful technique to (sparingly) have to hand.

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/