Boost logo

Boost :

Subject: Re: [boost] [warnings] Are warnings acceptable artifactsfrom builds?
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-09-08 18:02:36


Stewart, Robert wrote:
> Robert Ramey wrote:
>>
>> warnings vary with compilers. It's a huge amount of extra work
>> to eliminate all warnings in all compilers. And in many cases
>> "fixing" warnings really amounts to "hiding" warnings (e.g.
>> using a cast) so "fixing" them is worse than leaving them.
>
> Using casts doesn't hide warnings so much as tell the compiler that
> you have examined the context and want it to convert something
> anyway.
>
> Leaving warnings is worse than using a cast because library users are
> left to wonder whether there are problems in the library, can't find
> their own warnings and errors among your warnings, and can't build
> when they prefer to treat warnings as errors.

I'm not really unsympathetic to such a point of view. The problem is that
when you make a library which spans say - 8 compilers, it becomes
alot more work to try to quiet them all that it would first appear.
Naturally
with production code for one or two compilers you don't see this. Remember
the boost library code is filled with #ifdef's and such to deal with all the
small quirks and differences between compilers. Trying to suppress
all warnings for all compilers IS a lot of work.

Of course I'm not refering to simple/universal cases like replacing
f(int x) with f(int /*x*/) for an unused x - many libraries already do this.

consider the case where

T x;
...
int y = x;

where on one platform T is a char, another it's an unsigned char, on another
it's an int, and on another it's unsigned int. (This is actually the case
for wchar_t !).
Addressing this can take a lot of time and headache without really improving
the library in anyway.

Please let's not spend a whole lot of time on this particular example - I
needed a fast one for this email - if this one is not a good example - its
just because I didn't want to spend a lot more time looking.

Robert Ramey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk