local variable shadow
I find local variable shadow warnings helpful, but when I include various boost libraries, I have to remove a lot of shadowing within the boost functions themselves. Note that I'm not refering to name conflicts with my own code. How can I submit patches to remove these type of warnings? Thanks, -Chris
Once one starts adding patches to suppress warnings, you come upon the fact that compilers have different sets of warnings. And some warnings come with templated code. If one "patches" this, he can end up with and #ifdef/#endif mess. Worst of all, this is not apparent to the person who does the patching as he is concerned with one specific compiler so then the next person has to clean things up. Finally, In some cases there is a case to be made for shadow names. That is sometimes there is a global concept to be overloaded locally and this idea is expressed with name shadowing. Without doing this, one ends up with more names to keep track of in his head. And then there are warnings that a compiler emits which are totally bogus for the circumstance at hand. In one case of the serialization library I had to apply such a patch just because it was easier than explaining time and again why this warning was bogus for the particular case - its a warning not an error for a reason. This was just so people could get a "clean compile" That is a compile certified as "clean". So, though I see the appeal of the idea of applying patches to suppress warnings and I also see the appeal of making innocuos changes to make a clean compile (so real errors are highlighted), I'm not totally convinced its a good idea for code which is to be compiled on wildly varying platforms and abi environments. I believe that the work in propogating this to all the build environments is underestimated. Robert Ramey Chris Saunders wrote:
I find local variable shadow warnings helpful, but when I include various boost libraries, I have to remove a lot of shadowing within the boost functions themselves. Note that I'm not refering to name conflicts with my own code.
How can I submit patches to remove these type of warnings?
Thanks, -Chris
Thanks for getting back to me on this. I'm referring to warnings from gcc (-Wshadow), so it's not exactly platform specific, and I understand that there are many cases where you may want to shadow names... I'm referring to fairly straightforward cases such as for the pool allocator patch I proposed: http://lists.boost.org/Archives/boost/2007/02/116693.php I was mainly writing to try and find out if I was going through the right channels for this sort of thing, as I didn't get any feedback from boost@list. I can see you understand where I'm coming from:
...also see the appeal of making innocuos changes to make a clean compile (so real errors are highlighted)
so I can easily accept your argument against these kind of changes -- I'll let this go except to register my vote as a boost user in favor of such changes. -Chris On Mon, 19 Feb 2007, Robert Ramey wrote:
Once one starts adding patches to suppress warnings, you come upon the fact that compilers have different sets of warnings. And some warnings come with templated code. If one "patches" this, he can end up with and #ifdef/#endif mess. Worst of all, this is not apparent to the person who does the patching as he is concerned with one specific compiler so then the next person has to clean things up. Finally, In some cases there is a case to be made for shadow names. That is sometimes there is a global concept to be overloaded locally and this idea is expressed with name shadowing. Without doing this, one ends up with more names to keep track of in his head.
And then there are warnings that a compiler emits which are totally bogus for the circumstance at hand. In one case of the serialization library I had to apply such a patch just because it was easier than explaining time and again why this warning was bogus for the particular case - its a warning not an error for a reason. This was just so people could get a "clean compile" That is a compile certified as "clean".
So, though I see the appeal of the idea of applying patches to suppress warnings and I also see the appeal of making innocuos changes to make a clean compile (so real errors are highlighted), I'm not totally convinced its a good idea for code which is to be compiled on wildly varying platforms and abi environments. I believe that the work in propogating this to all the build environments is underestimated.
Robert Ramey
Chris Saunders wrote:
I find local variable shadow warnings helpful, but when I include various boost libraries, I have to remove a lot of shadowing within the boost functions themselves. Note that I'm not refering to name conflicts with my own code.
How can I submit patches to remove these type of warnings?
Thanks, -Chris
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Chris Saunders <ctsa@u.washington.edu> writes:
...also see the appeal of making innocuos changes to make a clean compile (so real errors are highlighted)
so I can easily accept your argument against these kind of changes -- I'll let this go except to register my vote as a boost user in favor of such changes. -Chris
No need to let it go. Robert only maintains one Boost library and others may well be willing to apply your patches. Submit them to the Boost patch tracker on SourceForge, and do your best to assign the ticket to the maintainer of the appropriate library. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (1)
-
Chris Saunders -
David Abrahams -
Robert Ramey