[wiki] Warning Guidelines for VC
A question just came up on IRC concerning the use of the /Za ("disable language extensions") and it not working. While searching for a previous post from STL on the subject [1] Google offered this link: <https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines> STL's (Stephan Lavavej's) advice on the subject was to *not* use /Za because it has "an extremely nasty bug". Unfortunately our guidelines suggest it should be used. I began to edit the wiki page but considering the amount of text and an example on the subject I thought it might be best to ask permission first. Should I edit the page to be in-line with STL's suggestion or just leave it as-is? [1] <http://lists.boost.org/Archives/boost/2010/04/165531.php > michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Caisse Sent: Thursday, December 30, 2010 8:48 AM To: boost@lists.boost.org Subject: [boost] [wiki] Warning Guidelines for VC
A question just came up on IRC concerning the use of the /Za ("disable language extensions") and it not working. While searching for a previous post from STL on the subject [1] Google offered this link:
<https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines>
STL's (Stephan Lavavej's) advice on the subject was to *not* use /Za because it has "an extremely nasty bug". Unfortunately our guidelines suggest it should be used.
"If it proves impossible to compile with the /Za option *(it is reported to cause trouble with the MS compiler, sometimes),* <<<<<<<<<<<< just document this, including in the build jamfile." was added before we got a definitive statement (admission?) from Stephen. I believe that it is still true that using /Za option will smoke out *some* portability issues and may be worth a try. Running it on all the many platforms is obviously the ultimate portability test. But you may be right that 'doing it right' causes more trouble than the potential benefits. We also don't know if the "an extremely nasty bug" is squashed in VC10, so the advice may be out of date. (I have also found that the /Za option causes hard-to-trace link errors if you don't use it in all libraries). If we change our recommendations here, we may be sentencing some groups of users to changing that their SOPs. If you have strong views on this, I suggest starting a new thread on this. Paul PS
I began to edit the wiki page but considering the amount of text and an example on the subject I thought it might be best to ask permission first. Should I edit the page to be in-line with STL's suggestion or just leave it as-is?
(I've been the 'author' of this - after discussions on the list, but you are welcome to change it - preferably after more discussions). --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 12/30/2010 02:05 AM, Paul A. Bristow wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Caisse Sent: Thursday, December 30, 2010 8:48 AM To: boost@lists.boost.org Subject: [boost] [wiki] Warning Guidelines for VC
A question just came up on IRC concerning the use of the /Za ("disable
<snip>
"If it proves impossible to compile with the /Za option
*(it is reported to cause trouble with the MS compiler, sometimes),* <<<<<<<<<<<<
just document this, including in the build jamfile."
was added before we got a definitive statement (admission?) from Stephen.
I believe that it is still true that using /Za option will smoke out *some* portability issues and may be worth a try.
Running it on all the many platforms is obviously the ultimate portability test.
But you may be right that 'doing it right' causes more trouble than the potential benefits.
We also don't know if the "an extremely nasty bug" is squashed in VC10, so the advice may be out of date.
(I have also found that the /Za option causes hard-to-trace link errors if you don't use it in all libraries).
If we change our recommendations here, we may be sentencing some groups of users to changing that their SOPs.
If you have strong views on this, I suggest starting a new thread on this.
Paul
Thanks for the response Paul. I don't have strong views primarily because I use the MS toolchain so infrequently. More than the "nasty bug" was the recollection from talking to Stephan at boostcon (and as indicated in his post) that they don't internally test the standard library with /Za. It seems that if the vendor isn't testing with it that it wouldn't be prudent to try.
PS
I began to edit the wiki page but considering the amount of text and an
(I've been the 'author' of this - after discussions on the list, but you are welcome to change it - preferably after more discussions).
I am happy to help but will defer to your judgment. -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On Thu, Dec 30, 2010 at 3:47 AM, Michael Caisse <boost@objectmodelingdesigns.com> wrote:
STL's (Stephan Lavavej's) advice on the subject was to *not* use /Za because it has "an extremely nasty bug".
Does anyone know if this "nasty bug" is fixed in the VC++ 2010 SP1 beta? --Beman
[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-... 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). Stephan T. Lavavej Visual C++ Libraries Developer
> -----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
[Paul A. Bristow]
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?
I personally characterize VC's compiler front-end C1XX as "pretty conformant" (*), but like all compilers it contains bugs and extensions of varying number, severity, and crawling evil. /Za had limited usefulness even before it became broken in VC10 because (a) according to my understanding it disabled some but not all extensions, (b) most of the extensions disabled by /Za would trigger warnings in its absence (notably the Evil Extension allowing modifiable lvalue references to bind to temporaries) at least at /W4 which is the warning level that everyone should use at a minimum, (c) it did nothing about bugs (I'd love to see THAT switch), (d) it also did nothing about unimplemented features (notably two-stage name lookup - dynamic exception specifications have been deprecated and export has finally been removed, yay). Over the years I've seen VC, GCC, and EDG disagree, with each of them being right and wrong in various cases. That's not to say that they're equally conformant, but after seeing rejects-valid and accepts-invalid behavior everywhere, you can't really trust a single compiler. Verifying portability by testing with multiple compilers, as Boost does, is the only reasonable course of action. (As EDG powers VC10+ Intellisense, we now test that our C++ Standard Library implementation compiles with EDG - if it doesn't, users will see spurious red squiggles in the IDE.) STL (*) Only the latest version.
On 12/31/2010 07:40 AM, Paul A. Bristow wrote:
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?
We might have different philosophies, but I would not have trusted any single compiler for that information. And while we all try our best for standard conforming code, in the end it is various compiler conforming code that must be written.
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'.
I often think of the Boost community as people who need to target multiple compilers/platforms. That might be wrong or too narrow. As far as Boost libraries are concerned, I think this is a non-issue. The code has to work with various compilers either at their least common conforming level or at various compiler specific alternatives. I don't see how the flag actually could help unless you were developing only on MSVC and then trying to port to other platforms.
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.
The more I think about it the more I would caution to not use the flag at all. The question that came up on IRC was with ASIO. The user reported that the resulting program "didn't work" with the flag and worked fine without it. If the MS Standard Library isn't even tested with the flag it seems like something I wouldn't use. I don't see the value it adds. I'm also not strongly attached to that as a published opinion because it is my secondary compiler at best. Thank you Paul for maintaining this wiki page and working through all the various issues that come up. Best regards - michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Caisse Sent: Saturday, January 01, 2011 12:12 AM To: boost@lists.boost.org Subject: Re: [boost] [wiki] Warning Guidelines for VC
On 12/31/2010 07:40 AM, Paul A. Bristow wrote:
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?
We might have different philosophies, but I would not have trusted any single compiler for that information.
Nor me! Not for "the most absurdly ambiguous language".
I often think of the Boost community as people who need to target multiple compilers/platforms. That might be wrong or too narrow. As far as Boost libraries are concerned, I think this is a non-issue. The code has to work with various compilers either at their least common conforming level or at various compiler specific alternatives.
I don't see how the flag actually could help unless you were developing only on MSVC and then trying to port to other platforms.
But I think this is exactly what is true for many developers, so the earlier the MS-only users get warning that they are in MS-only-land the better. I had hoped that /Za would achieve this.
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.
I am moving towards Michael's viewpoint, but I'd like more views on this before I make a change. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Caisse Sent: Saturday, January 01, 2011 12:12 AM To: boost@lists.boost.org Subject: Re: [boost] [wiki] Warning Guidelines for VC
I don't see how the flag actually could help unless you were developing only on MSVC and then trying to port to other platforms.
But I think this is exactly what is true for many developers, so the earlier the MS- only users get warning that they are in MS-only-land the better. I had hoped that /Za would achieve this.
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 MSVC-only-shop a little during development, loading and testing on the trunk remains the definitive test of portability.
I am moving towards Michael's viewpoint, but I'd like more views on this before I make a change.
In the absence of other views, I will change (when I can login ;-) the 'guidelines' page as above https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines including a reference to Stephen's informative and authoritative MSVC /Za summary at http://article.gmane.org/gmane.comp.lib.boost.devel/212186/ Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
[Snip Discussion on /Za] Hi Paul, I've also had problems with /Za that you discuss on the wiki page and at my current shop we don't use it, despite having developers who may compile on MSVC only prior to commit. Given we release with GCC too, this means we want to make the compilers as similar as possible. One way of doing this is to promote certain warnings to errors via compile flags e.g. we currently set /we4288 - For-loop scoping /we4238 - don't take address of temporaries /we4239 - don't bind temporaries to non-const references (Stephan's "Evil Extension") /we4346 - require "typename" where the standard requires it. /Zc:forScope - For loop scoping again /DNOMINMAX - don't define min/max macros Perhaps this alternate techinque might be mentioned on that page. Pete
On 01/07/2011 03:41 PM, Pete Bartlett wrote:
[Snip Discussion on /Za]
Hi Paul,
I've also had problems with /Za that you discuss on the wiki page and at my current shop we don't use it, despite having developers who may compile on MSVC only prior to commit. Given we release with GCC too, this means we want to make the compilers as similar as possible.
One way of doing this is to promote certain warnings to errors via compile flags e.g. we currently set
/we4288 - For-loop scoping /we4238 - don't take address of temporaries /we4239 - don't bind temporaries to non-const references (Stephan's "Evil Extension") /we4346 - require "typename" where the standard requires it. /Zc:forScope - For loop scoping again /DNOMINMAX - don't define min/max macros
Perhaps this alternate techinque might be mentioned on that page.
Pete
This is a great list Pete. Thank you for commenting! michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
/Zc:forScope - For loop scoping again
This one's on by default.
/DNOMINMAX - don't define min/max macros
This affects windows.h, not VC's compiler/libraries, just to be clear. STL -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Pete Bartlett Sent: Friday, January 07, 2011 3:41 PM To: boost@lists.boost.org Subject: Re: [boost] [wiki] Warning Guidelines for VC [Snip Discussion on /Za] Hi Paul, I've also had problems with /Za that you discuss on the wiki page and at my current shop we don't use it, despite having developers who may compile on MSVC only prior to commit. Given we release with GCC too, this means we want to make the compilers as similar as possible. One way of doing this is to promote certain warnings to errors via compile flags e.g. we currently set /we4288 - For-loop scoping /we4238 - don't take address of temporaries /we4239 - don't bind temporaries to non-const references (Stephan's "Evil Extension") /we4346 - require "typename" where the standard requires it. /Zc:forScope - For loop scoping again /DNOMINMAX - don't define min/max macros Perhaps this alternate techinque might be mentioned on that page. Pete _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stephan T. Lavavej Sent: Friday, January 07, 2011 11:42 PM To: boost@lists.boost.org Subject: Re: [boost] [wiki] Warning Guidelines for VC
/Zc:forScope - For loop scoping again
This one's on by default.
/DNOMINMAX - don't define min/max macros
This affects windows.h, not VC's compiler/libraries, just to be clear.
STL
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Pete Bartlett Sent: Friday, January 07, 2011 3:41 PM To: boost@lists.boost.org Subject: Re: [boost] [wiki] Warning Guidelines for VC
[Snip Discussion on /Za]
Hi Paul,
I've also had problems with /Za that you discuss on the wiki page and at my current shop we don't use it, despite having developers who may compile on MSVC only prior to commit. Given we release with GCC too, this means we want to make the compilers as similar as possible.
One way of doing this is to promote certain warnings to errors via compile flags e.g. we currently set
/we4288 - For-loop scoping /we4238 - don't take address of temporaries /we4239 - don't bind temporaries to non-const references (Stephan's "Evil Extension") /we4346 - require "typename" where the standard requires it. /Zc:forScope - For loop scoping again /DNOMINMAX - don't define min/max macros
Perhaps this alternate techinque might be mentioned on that page.
Indeed useful suggestions. added to version 9 8 Jan 2011 (but I have cautioned that /D nominmax may mask missing brackets, like (std::numeric_limits<result_type>::max)() that will be flagged by the inspection program later. Better to get it proof against the nasty min/max macros! Thanks Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
participants (5)
-
Beman Dawes -
Michael Caisse -
Paul A. Bristow -
Pete Bartlett -
Stephan T. Lavavej