On 3/26/2016 10:38 AM, degski wrote:
Hi Edward,
First of, thanks for your elaborate answer, explaining the extent of the issues.
The clang build which targets VC++ on Windows, as opposed to the clang
build which targets mingw(-64)/gcc on Windows, 'emulates' the non-standard VC++ preprocessor so it can compile Windows API headers and VC++ header files.
Do you imply here that the preprocessors of both Clang/LLVM and Clang/C2 work exactly the same way?
I don't know what you mean by Clang/LLVM and Clang/C2. But the normal clang preprocessor and the clang preprocessor which works when clang is built for Windows targeting VC++ are two different things. 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. They are two distinctly different implementations.
For all I know clang targeting VC++ may indeed work with those libraries if
the libraries pretend that clang targeting VC++ is VC++ for the intention of those libraries.
Isn't that the way to go then, to make boost act as if Clang/LLVM is VC14.
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++.
When using Clang/LLVM with the M$-STL there are no issues, so it must do a reasonable job AFAICS.
What makes you think there are no issues ? 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.
Clang/LLVM definitely flags quite a few of the non-confirming issues your own code might have, which implies that the VC14-STL does not have those kind of issues anymore.
Your logic does not follow.
Getting some of my older projects to compile (with Clang) at all is quite a hassle (looks like a different C++).
I made a suggestion to the clang developers that there 'emulation' of the non-standard VC++ preprocessor in their clang targeting VC++ implementation should be configurable so that when the compiler is not dealing with Windows API and VC++ header files it can be turned off and clang would then be the same C++ standard conforming preprocessor as it is with clang targeting mingw(-64)/gcc and clang on Linux and on the Mac. The suggestion was rejected. After that my interest in running clang targeting VC++ on Windows ended.
Again, why fight the Clang developers, go with the flow, Clang/LLVM wants to emulate VC++ perfectly, fine, should make your life easier no?
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. There is a big difference between these implementations. How would you propose supporting clang in preprocessor code considering these differences ?
...which 'emulates' the VC++ preprocessor in various unknown ways...
With the above position taken, those unknown ways would then hopefully be identified and emulated by the Clang team... M$ is in the loop as well, as far I understand, so it's not exactly reverse-engineering.
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.