Subject: Re: [boost] Official warnings policy?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2009-11-09 10:40:35
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On
> Emil Dotchevski
> Sent: Sunday, November 08, 2009 7:20 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Official warnings policy?
> 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."
> I would add that it my experience /Za doesn't make MSVC fully
> conformant anyway (I mean, in practice, not only in theory) and given
Thanks for this definitive and informed comment.
I might have been less 'sniffy' about it if I had seen the full quote ;-)
But I still believe that there may be value in Boost trying to use /Za for the
simple reason that, despite his " /Za isn't very useful" view, it *may* still be
useful for detecting portability problems, at the very least if it is found that
MS Extensions *are* needed.
I still believe that the work in fixing or suppressing warnings will actually be
small, and will be worth it.
Even if we don't find a single bug, that fact that we have tried harder gives
Boost a Quality feel.
--- 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