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