<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 10, 2014 at 12:55 PM, Edward Diener <span dir="ltr"><<a href="mailto:eldlistmailingz@tropicsoft.com" target="_blank">eldlistmailingz@tropicsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":c26" class="a3s" style="overflow:hidden">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.<br>

<br>
NO ! Please do not do that.<br>
<br>
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 library ).<br>

<br>
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.</div></blockquote>
</div><br>So, I feel like we're between a rock and a hard place here.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">At the same time, I'm quite sympathetic to not wanting to make things less conforming.</div><div class="gmail_extra"><br></div><div class="gmail_extra">But I don't see an easy way to have both. Here are my suggestions, but none of them are great:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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 check.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">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 implementation.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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 is Clang.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Does this make sense?</div></div>