Re: [boost] Official warnings policy?

Subject: Re: [boost] Official warnings policy?
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2009-11-10 18:27:27

Emil Dotchevski wrote:
> On Sat, Nov 7, 2009 at 11:18 AM, Mateusz Loskot <mateusz_at_[hidden]>
> wrote:
>> Beman Dawes wrote:
>>> 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.
>>>> Why would he do that for his own company's compiler?
>> Yes, however, does really Stephan recommends it? That would be the
>> first question.
> 
> What, you don't believe me when I tell you that STL personally told
> me that? :)
> 
> With his permission: "While /Za is supported (both by the compiler
> and the standard library), we recommend against using it. Although it
>  increases conformance in several areas (e.g. preventing unqualified 
> name lookup from reaching into dependent base classes), it isn't 
> subjected to exhaustive testing like the default setting is. There 
> have been and will probably continue to be examples of /Za exposing 
> compiler bugs that otherwise aren't exposed. For example, during 
> VC10's development, /Za's elided copy constructor check was being 
> triggered during move construction, when no copy constructor is being
>  called (even theoretically). In particular, if you compile with 
> multiple compilers, /Za isn't very useful - other compilers will 
> detect nonconformant code that /Za would have detected."

Driven by curiosity, I've exchanged e-mails with Stephan who provided
some further interesting details. Here we go:

<myself>Perhaps it would be useful to post a note on that to Visual C++
Team blog?</myself>

<Stephan>
That's a good idea. I've made a note to myself to write a blog post
about /Za. (I have some more work to do for VC10, and then I have to
blog about _ITERATOR_DEBUG_LEVEL and nullptr and rvalue references v2,
so this won't appear in the immediate future.)

By the way, the bogus elided copy constructor check that I mentioned was
worse than we thought. Unfortunately, the underlying problem in the
compiler isn't trivial to fix. We're going to try one more time to fix
this for VC10, but if the fix is deemed too risky, then things like
v.push_back(unique_ptr<int>(new int(1729))) simply won't compile under /Za.

Another thing to consider is that /Za is incompatible with <windows.h>.

You have my permission to quote any part of this mail.
</Stephan>

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org