On 4/5/2016 12: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.
Or it needed to replace them or provide instructions for them to be fixed. Comeau C++ (EDG-based) required this back in the day. IDK about now.
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).
MSVC target != Windows target
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.
The problem that I have with this is more fundamental. Microsoft should not get to unilaterally decide what C++ is on Windows--including the ABI (which by its nature can limit what parts of C++ even can be implemented). Regards, Paul Mensonides