[cfe-dev] MSVC /Za considered harmful

[Justin Holewinski]

On Wed, Jun 6, 2012 at 4:22 PM, Stephan T. Lavavej <
stl at exchange.microsoft.com> wrote:

> [Nathan Ridge]
> > Instead of asking them to get rid of it, why don't you ask them to fix
> it?
>
> I did. When I'm elected World Controller in 2012, I'll actually get
> everything I ask for. Or else.
>
> [Chandler Carruth]
> > (I would encourage folks to at least keep STL on the to-line, or mail
> him directly as he may not read cfe-dev as closely as others...)
>
> Thanks. I actually subscribed, then disabled mail delivery, since I wasn't
> planning to monitor cfe-dev for the MSVC bat-signal like I do for Boost. (I
> was planning to check the web archives for replies, and only later realized
> that I'd break threading if I didn't have any mails to reply to.)
>
> > The common problem is that standard library headers shipping with the
> compile *should* have access to the extensions.
>
> Yeah. In VC's STL, we definitely attempt to remain portable except when we
> absolutely must use extensions (e.g. DLL stuff, type traits compiler
> hooks), but the CRT, ATL/MFC, windows.h, and other libraries definitely
> vary in their use of extensions.
>
> > The right approach is for Clang to not set flags when being built by
> Visual Studio that are flaky or problematic.
>
> A few others that are hopefully not relevant:
>
> * /J is incredibly evil.
> * /RTCc breaks strictly conforming code by design (e.g. casts that
> truncate). I am barely willing to fix /RTCc problems in the STL when the
> fixes are trivial, but we don't run our tests with this.
> * /Wp64 is notoriously buggy (it has actually been command-line deprecated
> for three major versions: VC9-11). It suffers from false positives and
> false negatives, especially in templated code. The correct thing to do is
> to compile with a 64-bit-targeting compiler in order to catch 64-bit
> problems.
>
> [Benjamin Kramer]
> > The /Za flag was added to the build of clang not to encourage writing
> portable code but because an extension
> > was breaking perfectly valid c++ code for "pre-C++11 move emulation".
>
> I wasn't aware of that (but it doesn't surprise me - in fact I bet it's
> the Evil Extension).
>
> However, I consider breaking real move semantics to be more severe than
> breaking simulated move semantics.
>
> > I find the decision to deprecate /Za worrisome because it is a useful
> feature, but that's your choice
>
> It's actually the compiler team's choice (they have to worry about things
> like dev/test cost and breaking users; those aren't my costs and I love
> breaking users) - my preferences are certainly #1 remove extensions
> outright, #2 fix /Za, #3 remove /Za, #4 command-line deprecate /Za (as a
> prelude to #3), #5 notify people when we see them using /Za.
>
> > Coverage of building clang with msvc11 will probably decline sharply
> when it hits the market as setting up a build will require buying a license
>

Is this more of a legal or technical issue?  Right now, you can get a C++
toolchain from the "free" tools by installing Visual Studio 2012 Express
and then the Windows 8 SDK.  Both of these will presumably be free for RTM.
 I just built LLVM with this combination.

The Win 8 SDK even states "You can use the Windows SDK, along with your
chosen development environment, to write Windows Metro style apps
[...]; *desktop
applications that use the native (Win32/COM) programming model; ..."*


>
> I don't actually know anything about this subject (and I won't until I can
> get VC11 RTM in a VM), but if you care about command-line builds only (as I
> do), I believe that Magic 8 Ball says Outlook Good.
>

> > A few words to /W4: We experimented with having an automated builder
> using /W4 in the msvc8-days but it was very noisy and slowed down the build
> by 2x or so
>
> Compared to /W3, or compared to no (!!!) warnings at all? That is news to
> me.
>
> STL
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>



-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120606/4bf57372/attachment.html>