Hi Edward, I don't know what you mean by Clang/LLVM and Clang/C2. I wrote this earlier: "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." If you read John top-post you'll see he also refers to those two different compilers. By "targeting" on Windows I mean that clang is built to use either the gcc
RTL or the VC++ RTL. The version which targets the VC++ RTL has a VC++ conforming non-standard C++ preprocessor while the one targeting the gcc RTL has a C++ standard conforming preprocessor.
Targeting Windows and GCC (RTL) are two mutually exclusive notions. I guess you are referring to MinGW. although it works, one can hardly call it targeting windows, it's a usefull workaround for things that won't work otherwise ((like compiling OpenBlas.lib f.e., as there is no free native Fortran compiler on Windows, but this has issues, like obligatory dll's instead of static libs). They are two distinctly different implementations.
Sure.
No !!! Why should Boost support a non-conforming C++ preprocessor when a perfectly good conforming preprocessor is available from clang for anything which does not target VC++.
Boost is already supporting the non-conforming C++ preprocessor.
Try running Boost PP with a VC++ conformant preprocessor without the VC++ workarounds in Boost PP and you will find more issues than you can imagine.
Sure, but there's no compelling reason to try and do that. Your logic does not follow.
What I'm trying to get across is that Clang/LLVM treats the VC14-STL as bog-standard C++ (and it works, so it must be conforming). I know this, because it also assumes my own code is standard conforming and protests if it doesn't. It flags issues in Intel's Thread Building Blocks as well f.e.. Clang is used on Linux, Mac, and Windows and maybe a few other OSs I don't
know about. It only emulates VC++ when it is built for Windows targeting VC++. You still don't seem to understand that in the vast majority of its uses clang has a C++ standard conforming preprocessor while in a single one of its uses clang has a VC++ emulated non-standard C++ preprocessor.
Yes, I do understand that it's different. But boost is already supporting this different PP, as it is already supporting VC. The Clang team is doing the work here. I get your frustration, but in practice I don't see an issue. Feel free to offer "workarounds" in Boost PP and Boost VMD to deal with the
clang targeting VC++ 'emulation' because I know I will not be doing anything to get that 'emulation' working in those libraries. I have already been down that path with VC++ itself and will not be repeating that experience with another broken C++ preprocessor.
I've been looking at the approach John takes in the top-post and got a bit futher than he did. I'll answer to his post with my findings. Have a good day, degski