Switch to Clang
Because it compiles code faster on large code bases.
Because it is more C++11 compliant.
Because it will be updated with fixes in a timely manner.
Because it will require less of your maintenance.
Because you can contribute back to it to make it even better.
Because you can build tools out of it like Intellisense, static analysis, etc.
Because MSFT can focus on Visual Studio UI and other elements that make it a nice IDE.
Because this is what C++ developers would prefer (non-biased opinion here :P ).
Because code portability is important in this platform diverse world.
Seems like it would help fulfill the promise of: http://research.microsoft.com/en-us/collaboration/focus/cs/phoenix.aspx
Paul M commented
I think having the option to use clang or any other compiler would be a good move. At the moment trying to use some other than CL inside of VS is painful.
Jon, the only thing I could see being an issue would be Edit&Cont. All these other extensions could be integrated by MS. If there is a concern about IP; Apple does not open source ARC, blocks, or Cocoa, etc. If E&C is that important to users, add it again. Worrying about regressions, I understand. As far as 'errors.' If you're code was bad, and now you get errors, migrate. I'm sure MS could harness the power of clang to build a migration assistant. Oh yes, clang does that too...
Kostadin Petkov commented
How can I vote down!? You re insane dude....
It is invalid to say that Microsoft's compiler is less strict therefore we have a problem. Microsoft has the stated goal of full C++14 conformance which means that their relaxations must also go away (if nothing else, then as a compiler switch). These same relaxations can be easily implemented in Clang -- they are not implemented because Clang is a C++ compiler.
David Ziman commented
>>> CLang probably doesn't support Microsoft extensions for COM, WinRT, and .NET (e.g. ^ pointers, % references, property syntax, attributes... the list goes on and on) ....
Maybe Microsoft could build on it and make it happen?
>>> Windows developers will NOT like their compiler to suddenly give 500 error messages when they upgrade.
Clang provides the -fms-extensions command-line option which allows several Microsoft-specific extensions; however, the support isn't perfect. Maybe Microsoft could improve it?
Clang also offers -fdelayed-template-parsing. This may have alleviated the issues related to typename and this->., which you added to your code to satisfy two phase look-up. Would this have alleviated a significant quantity of errors?
>>> GCC error messages are horrible and worthless
One of the goals of Clang is to provide understandable expressive diagnostics . See http://clang.llvm.org/diagnostics.html for details.
I hope microsft can let c# run on LLVM too!
Some problems with this idea:
- CLang probably doesn't support Microsoft extensions for COM, WinRT, and .NET (e.g. ^ pointers, % references, property syntax, attributes... the list goes on and on)
- VC++ is not as strict as official C++ standards, e.g. in standard C++ you need a LOT more "typename" and "this->" prefixes in generic code. I ported some code to GCC and it was quite a painful transition (in large part because GCC error messages are horrible and worthless, but also because of the sheer number of changes required). Windows developers will NOT like their compiler to suddenly give 500 error messages when they upgrade.
David Ziman commented
It seems they are willing to explore things like AMP: http://blogs.msdn.com/b/nativeconcurrency/archive/2012/11/16/introducing-shevlin-park-a-proof-of-concept-c-amp-implementation-on-opencl.aspx
Are there any licensing issues they or the LLVM/Clang community would have to worry about if they contributed to the code or used it?
Is C++/CLI really C++? It isn't necessarily part of ISO/IEC 14882:2011.
How common is C++/CLI usage?
Does Clang support WinRT, any of the Microsoft specific extensions? Generate better code for targeting Win32? Support C++/CLI? Support visual studio debugging features such as edit and continue, static analysis, etc.
No? So switching to Clang would be a ridiculous thing to do as it doesn't do most of the things that VS-based C++ devs use day-to-day.