I suggest you ...

Switch to Clang

Why?

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

835 votes
Vote
Sign in
(thinking…)
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
David Ziman shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Thank you for the suggestion and the good discussion. There are a lot of great reasons expressed here for why switching to Clang would be a good or bad idea.

We’ve made Clang available for use in Microsoft projects as a preview in the Clang/C2 project. We will not move away from the MSVC compiler toolset in the forseeable future.

22 comments

Sign in
(thinking…)
Password icon
Signed in as (Sign out)
Submitting...
  • Microsoft, update VB6 programming & VBA programming commented  ·   ·  Flag as inappropriate

    Microsoft have a new Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008, Windows 7, Windows 8 and Windows 8.1, Windows Server 2012, Windows 10, and Windows Server 2016 ...
    https://docs.microsoft.com/en-us/dotnet/articles/visual-basic/reference/vb6-support

    Microsoft have extended support of VB6 to Windows Server 2016. VB6 is supported until at least November 2027 on Windows Server 2016, and until at least 2025 on Windows 10. Both are likely to be extended.

    VB6 programming is supported on Windows 10, Windows Server 2016 and earlier versions of Windows.

    VBA programming is supported on Office 2016 and earlier versions of Office.

    VBScript programming is still part of Windows.

  • Andrew Pardoe [MSFT] commented  ·   ·  Flag as inappropriate

    Thank you for the suggestion and the good discussion. There are a lot of great reasons expressed here for why switching to Clang would be a good or bad idea.

    We've made Clang available for use in Microsoft projects as a preview in the Clang/C2 project. We will not move away from the MSVC compiler toolset in the forseeable future.

  • Paul M commented  ·   ·  Flag as inappropriate

    @Ajay Vijayvargiya Meaningless idea? More like your comment is meaningless. How about some actual explanation as to why it is meaningless? The benefits are numerous - cross platform, all C++11/17 features working OOB.

  • aaron commented  ·   ·  Flag as inappropriate

    I like the idea of having a clang plugin for VS, that's about it.
    Oh, and remote debugging plugin with clang or gcc for linux.

  • Paul M commented  ·   ·  Flag as inappropriate

    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.

  • Dan commented  ·   ·  Flag as inappropriate

    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...

  • fg commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    >>> 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.

  • Qwertie commented  ·   ·  Flag as inappropriate

    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.

← Previous 1

Feedback and Knowledge Base