Microsoft promises Clang for Windows in November Visual C++ update Microsoft will integrate the Clang open source C and C++ compiler with Visual C++ in an update expected in November 2015, according to presentations given at the recent CPPCon 2015 event in Bellevue, near Seattle. Clang is a C, C++ and Objective-C compiler that generates intermediate code for LLVM, a related open source …
Developers will also welcome Clang because of its better standards compliance compared with Visual C++, for C as well as C++.
That's the "No shit, Sherlock" of the year! (hence, the icon.) Micros~1's approach to standards (those that are not their own, that is) has always been, "Yeah, we've heard of them". This is a complete reversal; the ability to finally have an actual, ANSI/ISO standards-compliant C/C++ compiler from Micros~1 (and one that includes all C++11/14 additions!!!) is unheard of.
My job just got a bit easier.
Now, the cynic in me thinks that this is purely an economic move on Micros~1's part; now they can ...what's the euphemism-du-jour..."make redundant"?...all the wankersdevelopers who are unwilling or incapable of generating a standards-compliant compiler. But why rain on my parade? Woot!
Having recently written a set of cross-platform (Linux, BSD, MS Windows) C libraries, I can say that working with MS VC was a major pain in the arse due to their incomplete and "uniqe" implementation of the standards. Going from GCC (for Linux) to Clang/LLVM (for BSD) was easy and seamless. Sometimes one compiler would warn about potential bugs that the other would miss (this goes both ways), but if the bug was fixed, both compilers were happy.
Going to MS VC though required lots of #ifdefs to cover the non-standard MS way of doing things, or the missing (not implemented) C library features.
These sorts of problems make porting major open source projects to MS Windows a major headache and requires a lot of work just to deal with the compiler differences. Patching Clang onto the front of Microsoft's back end may solve some of these problems.
It would be interesting to know how Microsoft intends to deal with C library differences. Is the resulting code going to use the Microsoft C library, or will it use the Clang/LLVM C library? And what happens when you link a program compiled with Clang/LLVM with a closed-source binary compiled with MS VC? Will it work? Will there be library clashes?
I won't be at all surprised if somewhere down the road Microsoft bins their own compiler and transitions over to Clang/LLVM.
By the way despite the waffly language of the article, Apple didn't create Clang/LLVM any more than they created Webkit. In both cases (and many others) they started using an already existing open source project.
By the way despite the waffly language of the article, Apple didn't create Clang/LLVM any more than they created Webkit. In both cases (and many others) they started using an already existing open source project.
LLVM was an existing open source project but I believe Apple did create clang.
Is it just me that finds this new Microsoft a bit scary and disturbing?? I'm not quite sure what they're gonna do next. It feels a bit like being given a cake by a serial killer.
"Is it just me that finds this new Microsoft a bit scary and disturbing?? I'm not quite sure what they're gonna do next. It feels a bit like being given a cake by a serial killer."
I don't find it scary and disturbing, no, but that doesn't mean I trust them even an inch. A well known phrase about a leopard and its spots comes to mind.
Yeah going from POSIX to POSIX even with different compilers is almost always more seamless than going coming or changing anything at all with code bases exclusively developed on VS.
POSIX nothing. MSVC doesn't even have a conforming implementation of snprintf. (Their "_snprintf" has the wrong name and wrong return semantics.) If they can't get the C standard library - which is part of the C language, ISO 9899 - correct, then POSIX / SUS needn't even apply.
Note that snprintf's been part of C for 16 years. The MSVC team's had enough time to fix this problem.
Speaking as a C++ author, this is wonderful news. I'll be slated by the penguinistas for saying this, but Visual Studio is by far and away the best development software ever written. X-Code is perhaps the second, both Eclipse and Embarcadero are a long way behind with CodeBlocks brining up the rear. All of them follow the layout of VS to some degree, but have less features.
Although MS has been behind in terms compliance for years, and the language features they choose to omit are occasionally somewhat random, their Visual Studio-2015 product has really turned a corner, having full 11 support at last and partial 14/17 support. Clang has tremendous compliance and great error messages, which is a serious failing of GCC.
Thankyou @StephanTLavavej, keep up the great work!
>Visual Studio is by far and away the best development software ever written
No it may be the best development UI but its all the other bits (compiler, libraries, etc) that make it a deal with the devil. This is good news in it is making that deal slightly less onerous.
I sure hope it links to something other than that terrible "Universal CRT" they foisted upon us in VS2015, because we all need to distribute an extra 41 DLLs with our apps right? (well for those of us stuck with app-local deployments anyway ... ) I've so missed the days of DLL Hell ...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
