31 Dec
2010
31 Dec
'10
3:40 p.m.
> -----Original Message----- > From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Stephan T. Lavavej > Sent: Friday, December 31, 2010 2:12 PM > To: boost@lists.boost.org > Subject: Re: [boost] [wiki] Warning Guidelines for VC > > [Michael Caisse] > > STL's (Stephan Lavavej's) advice on the subject was to *not* use /Za > > because it has "an extremely nasty bug". > > [Beman Dawes] > > Does anyone know if this "nasty bug" is fixed in the VC++ 2010 SP1 beta? > > When I encountered that bug (valid code like vector<unique_ptr<T>> triggers > compiler errors under /Za; the problem is that /Za performs an elided-copy- > constructor accessibility check during move construction when no copy > constructor is being called even theoretically), I asked for a fix, but > unfortunately the resolution was "won't fix forever". I can confirm that it will > not be fixed in VC10 SP1 RTW, and that there are currently no plans to fix it in > VC11. > > As a result, during VC10's development we stopped testing our C++ Standard > Library implementation under /Za, and I no longer consider it to be a supported > switch. (We support almost all switches, including the headache-inducing ones > like /Gr and /Gz, but we have to draw the line when valid code is broken.) > > I also asked for /Za to be removed from VC11, but that won't happen either. > (However, I was told that /Wp64, which was deprecated in VC9 and VC10, will > be removed from VC11. I don't think that's happened yet so I'll have to ping a > compiler dev about it. /Wp64 has always been broken - it suffers from false > positives and false negatives and interacts extremely badly with templates - and > it has been completely superseded by the existence of x64-targeting compilers.) > > My comments at http://blogs.msdn.com/b/vcblog/archive/2010/12/09/vs2010- > sp1-beta-what-s-on-it-for-c-developers.aspx#10103019 and below provide a > guaranteed-to-be-exhaustive list of the STL bugs fixed in VC10 SP1 Beta/RTW > (there are 3 in the Beta, and no more are planned for RTW; if that changes I'll > post about it), and a partial list of VC fixes in the SP1 Beta (I was able to dig up > most of the Connect bugs that were fixed). Well it's really good to get news from the 'horse's mouth' - even if the news is bad! So it would seem that there is no reliable way to determine if any code (including STL) is C++ Standard Conforming, apart from trying to compile it on a non-Microsoft Standard Conforming Compiler in strict mode? So while many, if not most, Boost Users will deplore this on principle, I fear we must be pragmatic and accept this, however unhappily. Fortunately, our extensive testing schedule using all the many compilers (using their 'strict' mode where possible) will reveal un-portability before any final Boost release 'hits the streets'. So unless there are other views, I propose to change the 'Dealing with warnings guidelines' to warn that the option is 'definitely dodgy'. (mainly by a link to this helpful post). Although /Za might help a little during development, loading and testing on the trunk remains the definitive test of portability. Thanks Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com