Hi, I have an interest in this thread. It seems (to me, but I might be wrong) not everybody is talking about the same thing. There are two usable versions of clang targetting VC, the (main) difference is in the back-ends, one has the LLVM back-end (http://llvm.org/builds/), the other the C2 back-end ( https://blogs.msdn.microsoft.com/vcblog/2016/01/20/clang-with-microsoft-code...). The Clang/LLVM compilers Clang-Cl.exe, Clang.exe and Clang++.exe are al just copies of the same file. It's unclear to me why M$ doesn't stick the C1 front-end to the LLVM back-end instead (as LLVM seems to consistently produce faster code), but it's M$, so what to expect. Both integrate into the IDE, Clang/C2 better than Clang/LLVM. Clang/C2 is Clang version 3.7.0, while Clang/LLVM is a (roughly weekly) snapshot build, currently at 3.9.0. Passing commands to Clang/LLVM in the IDE requires the use of -Xclang to precede the parameter passed to the (Clang/LLVM) compiler (directly in the command lines options). Although this is not the normal way to use the IDE, it is actually pretty handy, and gives good control. It seems that the VC14-STL-headers (and obviously only these) are sufficiently cleaned up to be handled by Clang/LLVM. The compatibility mode works fine, but with Clang/LLVM, they will be signalled out as microsoft-extensions. This does not happen when using the M$-STL (the one included with VC14!!!), so they seem good (unless things are happening in the background, I'm not aware about). I said earlier I was using Clang/LLVM/VS2015, but I use boost compiled with VC14. There are issues I've noted in another thread, there are undoubtedly more, but one can only use (and therefore test) so much of boost. Most of the compiled libraries libraries, I use, won't benefit much from clang compilation, f.e. filesystem, so I'm happy sticking with a VC-build. Others, like random (headers only for the important stuff), gets a huge boost :-) ) being compiled with the LLVM back-end. My point being (sorry for the windiness) that fixing the use (as a user) of boost headers in the setup of Clang/LLVM and VC14 should IMHO be first priority. This comes down to making Clang act as Clang (with clang-win) and not a mish-mash of VC and Clang. Clang and Cl (and the M$-STL) are moving towards each other, but it's still an ongoing process, and therefore a moving target. The promiss by STL (Steven, this time), is that in the end all will be good (a commitment to full adoption and adherence to the standards uptill and including C++17), but definitely not before VC15 (at the earliest). It would be great if some boost-vc-testers could also target Clang/LLVM/VC14. What could I do to make that happen? I admit I have little impetus to use clang on Windows targeting VC++ or
even the clang compatibility mode in the VC++ 14 IDE. Until the preprocessor problem is solved ( maybe it has been )
I don't really get what this means, could you please elaborate? What does "to use" and "the clang compatibility mode in the VC++ 14 IDE" mean. And what is "the preprocessor problem"? A good day to ya all, degski -- (\___/) (+'.'+) (")_(") This is Bunny. Copy and paste Bunny into your signature to help him gain world domination!