Re: [boost] [clang][preprocessor] Testing of clang emualting the VC++ preprocessor on Windows

Subject: Re: [boost] [clang][preprocessor] Testing of clang emualting the VC++ preprocessor on Windows
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-04-05 03:53:25

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/