Boost logo

Boost :

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" <>
>> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at