Robert Ramey
writes: as far as the serialization library is concerned, a many/most of these will be addressed. Can't guarentee that all of them will as some compilers (e.g. gcc) generate warnings on things that have in fact been done intentionally. When that happens, I consider the warning and verify that it's not relevant and move on. That is I just accept that fact that the warning is legitimate, and overriding it with my own judgement is also legitimate. "Hiding" warnings sort of defeats the purpopse of warnings in the first place and tweaking code to avoid warning on all compilers is very compiler dependent - and most of already spend too much time on circular, pointless quests.
Serious warnings should be dealt with. At our company in the past however, one of the main products buided with 170 warnings. No way to detect the serious ones from the innocents. So then we introduced the 'warning as errors' policy and surpressed the really stupid ones. A developper now has to fix the warnings or code won't compile. Result 0 warnings. External header warnings are supressed by pragma's, which is good enough imo. I can give the example of the 'unused argument' warning, which indicates a potential forgotten argument or just a not needed argument. If it is the first option, the compiler found a bug; if it is the second case one can simply supress it by commenting it out (or use BOOST_UNREF macro) or maybe rearrange the prototype of the function. void f(int /*i*/) { //yes no warning }