<div dir="ltr"><div class="gmail_extra"><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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br></blockquote>
<div><br></div><div>I've done a lot of preprocessor metaprogramming in the past and I am extremely sympathetic here. A few years ago, I think in in the context of trying to get Paul to get Chaos into the Boost review queue (one of several times), one of his reasons for not doing so was because he did not want to support broken preprocessors -- especially Microsoft. It still should get in anyway, but that's another story.</div>
<div><br></div><div>I've never implemented a C preprocessor (thankfully), but one thing that I've wondered about that may actually be feasible and may allow for a way forward, is to have a pragma that allows you to toggle between the buggy MS-style preprocessor and a compliant one. The idea is that when any macros are defined while the buggy mode is on, those macros internally behave as they would if defined in Microsoft's broken implementation whenever they are expanded. Similarly, if the toggle is the other way (specifying compliance), then everything works as expected in a compliant preprocessor implementation. In other words, preprocessor definitions, depending on the state of the toggle at the time they are defined, internally behave differently upon expansion. If a compliant-mode definition invokes a non-compliant macro, the MS-emulation only happens internal to the broken macro's expansion. Similar-but-opposite behavior would be expected when the composition of the macros is flipped (note that this would be less important to support than the latter). Hypothetically there could also be a way at the command-line to specify that certain include paths should always have this broken preprocessor option on for the duration of the include, whereas by default, other files do not (the default could be switched, but I think this would be ideal).</div>
<div><br></div><div>The idea of all of this is that in the vast majority of cases (I have no numbers on this, but I think it's a reasonable hunch) the only reason people care about MS preprocessor emulation is because they need to preprocess MS headers or other libraries that they, themselves, have not written. I'd be surprised if a lot of people had preprocessor-heavy code that is difficult to fix, but if they did, they could opt-in for the broken preprocessor if they so chose. At the very least, libraries like Boost.Preprocessor could use the pragma so that they don't need to bend-over-backwards to try to support another implementation (clang's preprocessor is already awesome in this respect).</div>
<div><br></div><div>Again, I have not thought through this very deeply and do not have the experience here necessary to say whether this is actually feasible or not, but I present it as an option hoping that someone out there who does have the experience can at least consider it. The whole point of this is that emulating MS's preprocessor bugs allows "proper" preprocessing of broken-but-important headers and so its importance cannot be stressed enough. On the other side, producing a sort-of-like-MS preprocessor that everyone is stuck with just because of Windows headers is itself a horror. I'm not entirely convinced that we can't somehow have our cake and eat it too in this particular instance.</div>
</div><div><br></div>-- <br>-Matt Calabrese
</div></div>