Boost logo

Boost :

Subject: Re: [boost] Official warnings policy?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2009-11-07 11:12:07


> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On
Behalf Of
> Beman Dawes
> Sent: Saturday, November 07, 2009 1:47 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Official warnings policy?
>
> On Sat, Nov 7, 2009 at 7:13 AM, Daniel James <daniel_james_at_[hidden]> wrote:
> > On 07/11/2009 10:38, Paul A. Bristow wrote:
> >>>
> >>> Stephan Lavavej from Microsoft told me that that this option triggers
> >>> known bugs in the compiler. He strongly recommends to stay away from it.
> >>>
> >>
> >> Sounds like spreading FUD (Fear Uncertainty and Doubt) to me.
> >>
> >
> > Why would he do that for his own company's compiler?
>
> Stephan is a well-respected member of the VC++ team. If he recommends
> staying away from a particular feature, we can rely on that as good advice.

Well I find it worrying advice - especially as I've followed my own advice
without detecting any ill effects.

(Hopefully it is fixed in the next compiler release ;-)

If library writers find it works OK, we users are more confident that it is
portable and 'more' C++ standard compliant.

If it causes trouble (as it surely will as you pointed out with
Boost.Filesystem) they can simply document that using \Za doesn't work. No
problem.

Meanwhile, I've tidied up a bit at

https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines (go to
the end)

but what I think we need is several more examples, and examples of suppressing
gcc warnings too, especially worst-case examples where MSVC produces one warning
and gcc produces another (and so #ifdef _MSC_VER ... #endif #ifdef GCC.. #endif
is needed.

If also needs input from other compiler users.

If you have examples, either add to the wiki directly or email to me and I will
add.

We also need consensus that what I've suggested is actually the best advice.

Collectively we already know how to do this, we just need to make it easier for
library writers and maintainers to get on and do it.

But I doubt if it is worth delaying release.

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal, UK   LA8 8AB
+44 1539 561830, mobile +44 7714330204
pbristow_at_[hidden]

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