On 4/5/2016 3:53 AM, Niall Douglas wrote:
On 4 Apr 2016 at 16:21, Paul Mensonides wrote:
I am not referring to VC++. I am referring to clang intentionally conforming to VC++ rather than conforming to the Standard. That decision is crap and the mentality that produced it is also crap. The same is true for any other intentional nonconformance.
Until very recently - VS2015 Update 2 - clang needed to behave like MSVC in order to grok Windows system headers.
Now Windows system headers are (apparently) standards conforming, clang no longer needs to behave this way. Hence me submitting feature request https://llvm.org/bugs/show_bug.cgi?id=27169 to have winclang no longer implement a broken preprocessor except in msvc compatibility mode.
(Note as of Update 2, -fms-compatibility is no longer needed to use clang with a MSVC target. An enormous improvement).
What it says to me is either that clang's popularity is more important to the clang project than clang doing the right thing (i.e. decisions based on benefitting clang (popularity/adoption/etc.) not on benefitting the C++ community) or that the clang project's technical decision-making is extremely shortsighted--or both.
I think their decision making here is far more driven by lack of resources than anything else, only a tiny - if very productive - segment of clang's dev team work on MSVC ABI support. They needed to sell to management the need for a MSVC ABI target. That means telling a very simple compelling use case story. As Microsoft have now picked up clang for Visual Studio and have finally repaired their headers, I'd call that simple story a resounding success.
This is about what clang is doing, not Microsoft. Microsoft has intentionally disregarded the Standard repeatedly over a long period of time.
The Microsoft compiler team had strong business reasons to do so. Their biggest customer is Microsoft itself, and parts of that org want a broken preprocessor and other deviations from the spec. Everyone I know in the compiler team would *just love* to conform to the standard more closely, but in the end your biggest customers drive the product.
They are getting better, slowly. That's old news. Clang, however, has now made a decision to intentionally disregard the Standard as well in order to attempt conform to Microsoft's definition of C++. Microsoft lost my respect a long time ago and has yet to regain it. Clang has now lost it as well.
Microsoft decided to resource a clang port to Visual Studio some years ago. Gaby dos Reis indeed did much of the original prototyping of clang married to C2 codegen to see if it was viable. That's now a shipping product. Microsoft are tidying and fixing up the rest of the tool ecosystem to become as standards conforming as any other ecosystem, indeed some would argue that STL has been a bit *too* standards conforming in the MSVC STL in that he has exchanged performance in a number of places for a very strict interpretation.
Whatever respect you have for whom is your business, but no one can argue that very significant resources have been directed at this over many years, and it is having big effects. There is every reason to expect that the MSVC ABI target will be 98% C++ *17* standards conforming by end of 2017. Most of the missing 2% are due to legacy ABI problems e.g. the MSVC mangling system can't easily express lambda types in template args etc. That's as good as is achievable on an ABI approaching thirty years old and long preceding ISO standardisation.
Microsoft are also the only vendor shipping finished editions of many of the 17 era Library Fundamentals. VS2015 ships a very high quality implementation of the Filesystem TS for example, indeed it has fewer quirks than Beman's edition in Boost. I understand that is only going to improve in the next two years as Modules, Concepts and Coroutines all land, and by 2018 it is highly likely Microsoft's C++ dev environment will meet or exceed that of any other major vendor bar none.
Like you, I'll believe that when I see it, but the trends are looking excellent. Microsoft is back to being competitive in C++ after a gap of over twenty years.
And when does Microsoft actually ship a version of VC++ with a C++ standard conforming preprocessor ? Nobody is holding their breath for this just as nobody has held their breath for this over the last 25 years, during which Microsoft has repeatedly made noises that they will fix their non-standard conforming preprocessor and never have done so. All this talk of yours about how conformant to the C++ standard Microsoft is becoming means nothing unless they can fix the preprocessor. The rest of your touting of how serious Microsoft is in conforming to the C++ standard is just "show business" to me. Whatever Microsoft ships as their backend compiler, whatever noises they make about being serious about conforming as closely as possible to the C++11 or C++14 or C++17 standards, if they can't ship a C++ standards preprocessor they will never be conformant to the C++ standard.