On 3/26/2016 12:58 AM, degski wrote:
Hi,
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"?
The VC++ preprocessor is not a C++ standard conforming preprocessor. Both Boost PP and Boost VMD perform various tricks to get the VC++ preprocessor to mostly work with those heavily macro based Boost libraries. This working with VC++ in Boost PP and Boost VMD depends on identifying the VC++ compiler. Many other Boost libraries use Boost PP so using those other libraries with VC++ are affected by all the workarounds in Boost PP to get the non-standard VC++ preprocessor to be workable with Boost PP constructs. 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. Exactly what VC++ preprocessor 'bugs' it emulates and how successful this emulation is I do not know, but I know it is done because I was told of it in the clang developer forum and I encountered a clang targeting VC++ preprocessor 'bug' which was explained to me as an emulation of VC++. It was hard enough work for Paul Mensonides to get the VC++ preprocessor to work with Boost PP and it was hard enough work for me to get the VC++ preprocessor to work with Boost VMD that neither I nor, I assume, Paul wants to go back and figure out another set of preprocessor 'bugs' to get clang targeting VC++ to work with those libraries. 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. Since I have been basically taking care of Boost PP and since I am the author of Boost VMD I have not tried clang targeting VC++ as VC++ in those libraries since I do not want to be tasked with fixing another set on non-standard C++ preprocessor bugs for another compiler if it does not work. 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. Unless you have dealt with it personally you cannot know how difficult it is doing the sort of preprocessor programming which Boost PP does and Boost VMD does with the VC++ preprocessor. Being asked to work with another preprocessor which 'emulates' the VC++ preprocessor in various unknown ways is not a task I wish on anybody. I fully understand why the clang developers in their efforts to have clang on Windows work with VC++ had to 'emulate' the non-standard C++ preprocessor to work with Windows API and VC++ header files, since enough quirks in those header files have depended on the non-standard VC++ preprocessor. But propagating that non-standard preprocessor behavior to all preprocessor processing is IMO a major mistake, especially as the normal clang preprocessor is very good and C++ standard comnforming.