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