
Hi.. I've introduced boost as a utility libraries for the projects I work on. However, all of the people working on these projects compile code using the -Wshadow option. This generates lots of pages with warnings that clutter their compilation and makes it very hard for them to see what the real warnings and errors are in our code. I don't mind shadowing in the cpp compiled in boost, but shadowing in the header files are bad since these will show up for every piece of code we compile that uses boost. Consequently, I'm altering our boost library to remove the shadowing warnings we see.. This is a tad boring, but it works.. Only trouble is that when we at some point want a newer version of boost, we have to do it all over again. Any chance boost can be compiled with shadow warnings, making the boost developers not use shadowing? I don't see any reason to actually use shadowing. Having a local variable and a class member with the same name is just ground for confusion and subtle errors. From the code I've seen fixing names of local variables, I see that many variables have had an underscore added to the name to prevent shadowing already, why not use this consistently? Regards.. Haakon Humberset

Haakon Humberset <humbe@yahoo-inc.com> writes:
Hi..
I've introduced boost as a utility libraries for the projects I work on. However, all of the people working on these projects compile code using the -Wshadow option. This generates lots of pages with warnings that clutter their compilation and makes it very hard for them to see what the real warnings and errors are in our code.
I don't mind shadowing in the cpp compiled in boost, but shadowing in the header files are bad since these will show up for every piece of code we compile that uses boost.
Consequently, I'm altering our boost library to remove the shadowing warnings we see.. This is a tad boring, but it works.. Only trouble is that when we at some point want a newer version of boost, we have to do it all over again. Any chance boost can be compiled with shadow warnings, making the boost developers not use shadowing?
I don't see any reason to actually use shadowing. Having a local variable and a class member with the same name is just ground for confusion and subtle errors. From the code I've seen fixing names of local variables, I see that many variables have had an underscore added to the name to prevent shadowing already, why not use this consistently?
The use of member function shadowing (not involving variables at all) is a fundamental design technique in the Boost Iterator library (e.g. iterator_facade et. al.). -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
David Abrahams
-
Haakon Humberset