I have been told, via my bug report on a preprocessor error in the
latest version of clang-cl.exe, that clang-cl.exe is trying to
emulate at least some of the bugs of the VC++ preprocessor.
NO ! Please do not do that.
I know, from having worked on variadic macros in Boost PP and having
created my own variadic macro data library, how broken the VC++
preprocessor is when it comes to preprocessor metaprogramming. Paul
Mensonides, the creator of Boost PP and an exceptional expert on the
C++ preprocessor, also knows and has bemoaned countless times how
difficult it is to do preprocessor metaprogramming if one has to
deal with the VC++ preprocessor. Not only will clang-cl.exe's
emulation of the brokeness of the VC++ preprocessor set back further
efforts in metaprogramming preprocessor code and libraries but there
is absolutely no chance, if it means anything to clang-cl
developers, that any effort will be made to accomodate clang-cl's
preprocessor bugs into Boost PP ( or my own variadic macro data
This is completely the wrong direction for clang-cl to go. Please
stop and only consider producing as close to as possible a 100% C++
conformant preprocessor, as the rest of clang no doubt has as its goal.
So, I feel like we're between a rock and a hard place here.
At a fundamental level there are bugs we need to be bug-for-bug
compatible with because there is large amounts of existing code in the
wild relying on those bugs.
At the same time, I'm quite sympathetic to not wanting to make things
In the case of the VC++ preprocessor you really have to be a masochist, and someone with little pride in correct C++, to want to emulate the bugs there.
But I don't see an easy way to have both. Here are my suggestions, but
none of them are great:
1) Make sure that any bug-compatibility is inspired by actual code
relying on the bug. I suspect it is in this case, but its always good to
This is a fool's errand, sir. You have no idea of all the "existing code in the wild". Do you really think because someone has written a macro that relies on the non-conformance of the VC++ preprocessor that it is clang-cl's responsibility to reproduce that same preprocessing bug ? Or even a theoretical someone.
2) It may be desirable for Boost (and Boost users) to opt into a more
strict mode. I get the flags backwards all the time (Reid or someone
else will correct me) but we have two flags to control compatibility:
one for essentially conforming (or at least not horrible broken)
extensions, and another for bug-for-bug compatibility. I think the
latter is '-fms-compatibility' while the former is '-fms-extensions',
but again, i get them backwards. Anyways, perhaps Boost would want to
use '-fno-ms-compatibility' where possible to get a more conforming
I do not ultimately control the Boost PP library, Paul Mensonides does although I am a contributor, but I can almost guarantee you that he has no inclination, and I know I have none, to make any changes to accomodate clang-cl's emulation of VC++ preprocessor bugs no matter what compatibility options and emulation of whatever VC++ preprocessor bugs clang-cl wants to promote. And if others are willing to go into that Boost PP code and hack around with it given the ridiculousness of clang-cl attempting to emulate the brokeness of the VC++ preprocessor in whatever respects, I wish them the best of luck through their hair-pulling and tears.
3) I think we should then make sure we expose macros you can use to
detect the bug-for-bug compat mode, and use the (horrible) cl.exe
implementations of things like Boost PP, even though the host compiler
Does this make sense?
Not to me. The only thing that makes sense, quite honestly, is that clang, and clang-cl, produce a C++ standard conforming preprocessor. Furthermore there is no way you will ever get Microsoft to fix their broken preprocessor if you think that emulating their own preprocessing bugs is the way to go. If you want to make a switch in clang-cl to produce a standard conforming preprocessor, rather than have it be the default, my message to anyone using Boost will be simply that without this switch there is no point in using Boost in their code. Of course if this does not matter they can do what they want.
Please, please reconsider the notion that you can produce a compiler worthy of clang, to be used by VC++ programmers, by reproducing VC++ preprocessor bugs. This is a realy bad path to take.