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/