On 3/28/2016 7:17 AM, Peter Dimov wrote:
Edward Diener wrote:
I need to know what are the preprocessor defines being set by clang when it is in the mode that supports VC++. Is both __clang__ and _MSC_VER defined in all cases ?
They are, although I'm not sure whether _MSC_VER is enabled by -fms-compatibility, or just by -fms-extensions. If the latter, it won't be possible to reliably detect the former. I also don't know which of those flags enables the broken preprocessor.
According to what I was able to find out in the clang developers mailing list the presence of _MSC_VER being predefined along of course with __clang__ being predefined means that clang is implementing the emulation of the VC++ non-standard preprocessor. Also, aside from clang-cl, the clang or clang++ executables can also cause this emulation of the VC++ non-standard preprocessor whenever it is targeting an MSVC environment. I did not find out all the command line switches by which clang/clang++ is targeting an MSVC environment but I was given the switch '--target=x86_64-windows-msvc' as an instance of this targeting of an MSVC environment from clang/clang++ directly. I am currently testing changes to my local Boost PP develop /boost/preprocessor/config/config.hpp file which enables clang with _MSC_VER being defined to act like VC++. This file controls certain general compiler identification both for Boost PP and Boost VMD, which makes compiler workarounds in both libraries possible. If I have any trouble testing clang-cl, given the messages in this thread, I will post back asking for further help. Once I finish local testing I will update the develop branch with my changes. Afterwards if they are any problems with clang's emulation of the VC++ preprocessor for library developers whose libraries use Boost PP and who want to test with clang targeting VC++ I would expect those developers to report such problems to clang. As I realize I have been perhaps too adamant in saying I do not want to be taxed with the problem of figuring out a possible problem in clang's emulation of VC++ preprocessor in Boost PP or Boost VMD when the VC++ workaround itself does not have the same problem. But if this actually happens others are welcome to fix such issues if they occur or create PRs for them, as well as reporting the issue to clang if that's what they want to do. Hopefully no such problems will come up, but as someone who has encountered VC++ preprocessor quirks in Boost PP and Boost VMD I will be a bit amazed if the clang developers, as good as they are, have emulated all of them, whatever actually causes them, correctly.