[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] [1.34.0beta] many, many warnings... :(
From:       "Sohail Somani" <s.somani () fincad ! com>
Date:       2007-05-02 16:42:56
Message-ID: 1C1EBEF8DBACDC439D038EA051674EC78A4693 () xbox ! financialcad ! com
[Download RAW message or body]

> -----Original Message-----
> From: boost-bounces@lists.boost.org 
> [mailto:boost-bounces@lists.boost.org] On Behalf Of Vladimir Prus
> Sent: Wednesday, May 02, 2007 9:40 AM
> To: boost@lists.boost.org
> Subject: Re: [boost] [1.34.0beta] many, many warnings... :(
> 
> Stefan Seefeld wrote:
> 
> >>>>> <pick your favorite color>.
> >>>> The problem is that the current regression reporting 
> tools don't count
> >>>> warnings (previous version use to), so there's nothing
> >>>> nagging developers
> >>>> about warnings introduced in their code.
> >>> If you treat warnings as errors
> >> 
> >> Fine we me, but not necessary fine with everybody ;-). And 
> I suspect
> >> Boost.Build's warnings-as-errors=on work only with few compilers.
> >> But few is better than none.
> > 
> > The problem is that some warnings can't be avoided, at 
> least not if you
> > try to be portable.
> > (Example: As discussed in a different thread: putting in a return
> > statement to satisfy some compilers may trigger a 'unreachable code'
> > warning on others.)
> 
> I think BOOST_AVOID_WARNING_XXX macro can be used to suppress 
> a warning
> in compiler-specific way.
> 
> We probably can use warnings-as-errors only for gcc and msvc, 
> to reduce
> portability burden.

That sounds an awesome idea. Shall I file a bug? :)

Sohail

[prev in list] [next in list] [prev in thread] [next in thread]