On 3/30/2016 7:16 PM, Peter Dimov wrote:
Edward Diener wrote:
There are quite a few failures in this clang emulation of the VC++ preprocessor when tested against the preprocessor test code. In fact testing clang emulation of VC++ preprocessor when I don't treat clang as VC++ in Boost PP, but as its normal C++ standard conforming preprocessor, still fails a few cases but far less than when clang is treated as VC++ in Boost PP.
I suppose that the right thing to do here from user point of view (if that's not too much of a hassle, of course) would be to use the conforming mode for the parts that work under it, and the VC++ mode for those that work under it, and if something doesn't work with either, tough luck. :-)
Boost PP is not set up to switch modes. Figuring this out is not a possibility AFAICS, and it is not something I want to spend any time in doing. The problem is clearly that of clang. They have made this mess and it is not up to Boost to fix it IMO. Of course anybody else that wants to tackle this, including yourself, can do it if they like. I suggested to the clang developers, based also on some other people's comments, that it should be possible of them to setup their VC++ targeting so that the emulated VC++ preprocessor is used to expand macros when it is needed for certain header files ( Windows API, VC++ compiler distributed header files ) but that their C++ standard processor should be used otherwise. But they evidently did not want to do that. Even such a simple scheme as having a #pragma to specify one or the other preprocessor behavior they did not want to consider. Asking programmers to support another broken C++ preprocessor at this stage of C++'s development history is a travesty. And all simply because Microsoft has refused for a quarter of a century to fix their C++ preprocessor implementation, which they well know has always been non-standard.