Re: [boost] [1.34.0beta] many, many warnings... :(

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-05-06 08:25:56

Vladimir Prus wrote:
> David Abrahams wrote:
> 
>> on Sat May 05 2007, "Jonathan Franklin" <franklin.jonathan-AT-gmail.com>
>> wrote:
>>
>>> AFAICT gcc will only gripe if the base class defines virtual methods but
>>> no
>>> virtual dtor.  Perhaps this isn't the case with older versions of the
>>> compiler.
>>>
>>> I still need to read up on the issues WRT is_polymorphic, since they
>>> obviously exist given David's previous statements.
>> Oh, maybe not.  I don't remember the precise issue.  However, it's
>> easy to imagine that that particular warning could have been defined
>> differently.  My point is that most warnings aren't hard errors for a
>> reason: there are legitimate use cases for the code being warned
>> about.
> 
> As a practical matter, if your code has 100 false warnings, there's no chance
> you'll notice 101-th warning that's result of real bug. Therefore, you either
> eliminate all warnings, enable -Werror and investigate all new warnings that
> occur, or you don't use warnings at all. I prefer -Werror, and therefore if
> Boost headers produce zillion of warnings, that's rather bad.
> 
> Now, it might be impractical to expect anybody to spend day workarounding 
> an obscure warning on a compiler nobody uses, but all warning patches I saw
> posted are rather simple, so maybe there's no hard-to-workaround warnings
> at all. 

I'm inclined to agree. While eliminating all warnings from all compilers 
isn't realistic, we should have procedures in place to detect and 
eliminate warnings from common compilers where the fix doesn't have 
undesirable consequences.

In effect, Boost is beginning a period of reengineering for some of our 
core procedures. The first task is the move to Subversion. The second 
task is the new release management procedure (and that probably implies 
at least some reengineering of how we do testing.)

It looks like our patch management needs an overhaul too. I don't know 
what that might look like, but once the new release procedure has firmed 
maybe we can look at how to better integrate patch management into our 
development process.

--Beman