On 2/15/2015 3:22 AM, Andrey Semashev wrote:
On Saturday 14 February 2015 17:53:51 Edward Diener wrote:
On 2/14/2015 4:52 PM, Andrey Semashev wrote:
My position on this issue is that as long as clang team aims for compatibility with MSVC, they should make clang work similarly to MSVC.
Actually clang only aims for compatibility with MSVC in their clang for Windows version which targets VC++. In their clang for Windows implementation which targets mingw/gcc they do aim for a certain amount of compatibility with mingw/gcc.
Hmm, I didn't know there were two clangs for Windows. Confusing... Anyway, since gcc compiles this code the same argument applies.
The clang developers decided they wanted a version of clang which could replace VC++ in Visual Studio. Unfortunately to do so they have sought to replicate all VC++ bugs, including those of VC++'s broken preprocessor. I have worked with Paul on Boost PP and neither I nor he ( presumably ) are willing to find a further set of workarounds for yet a different set of VC++-like preprocessor bugs to accomodate clang for Windows targeting VC++. So I don't bother with trying to use that version of clang on Windows ( often called clang_cl ). The other clang for Windows targets mingw(64)/gcc and while it is very close to the Linux version of clang there are a few subtle differences due to the fact that it run under Windows and produces Windows dlls and exes. That's a version I can test with and which is supported in Boost and by Boost Build, and it's the version which shows the clang 'export' bug on Windows which I have brought up with the clang developers. The bug manifests itself using Boost with Boost.Test which exports the ExecutionMonitor class, which is non-copyable and non-assignable. In the past I had tried to convince the clang developers that the broken VC++ preprocessor that they are trying to replicate in the clang Windows version targeting VC++ should only manifest its brokenness when dealing with VC++ header files ( where evidently such brokenness is needed ), but should work like clang's normal C++ standard preprocessor otherwise. But they did not want to implement that AFAICS. In which case I do not believe that using that version with most Boost libraries is ever going to work. However using the clang version that targets mingw(64)/gcc on Windows should give one a very good C++ standard conforming compiler to test Boost with on Windows. This should give some explanation of the two different versions of clang on Windows. They can be distinguished in code by the fact that the clang version targeting VC++ defines the _MSC_VER macro and the version targeting mingw(64)/gcc does not define the _MSC_VER macro. Thanks for your concern here regarding Boost. I probably should not have brought up the issue of the bug here but I was thinking ( erroneously ) of finding a simple workaround in config for it until it gets officially fixed by clang.