From: gast128 (gast128_at_[hidden])
Date: 2007-08-14 17:52:25
> Robert Ramey <ramey <at> rrsd.com> 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
}