[cfe-dev] Clang-cl.exe and the VC++ preprocessor
Edward Diener
eldlistmailingz at tropicsoft.com
Thu Jul 10 13:56:54 PDT 2014
On 7/10/2014 4:08 PM, Aaron Ballman wrote:
> On Thu, Jul 10, 2014 at 3:55 PM, Edward Diener
> <eldlistmailingz at tropicsoft.com> wrote:
>> 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 library ).
>>
>> 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.
>
> I have the opposite view. Having an MSVC-compatible preprocessor is an
> excellent thing for interoperability on the platform.
Am MSVC-compatible preprocessor is a broken preprocessor. How can this
be an excellent thing ? If the idea is to emulate VC++ in every respect,
there is no point in using clang-cl. Really !
> It increases the
> likelihood of adopting clang as a native toolset on Windows, and
> reduces the barrier to entry, because it allows me to take code which
> compiles with MSVC and instead run it through clang.
Again there is no point in using clang if you are just going to emulate
VC++. Is not the idea to produce a standard conforming compiler for
people to use on their VC++ code which is better and cleaner than VC++
with all its bugs.
>
> This functionality is behind a flag (-fms-compatibility), and it would
> be a step backwards to say "please turn on compatibility with MSVC,
> except for the preprocessor" when that flag is enabled. It would also
> prevent using MSVC's STL (IIRC, <type_traits> relies on this behavior
> in MSVC 2012 due to the compiler's lack of support for variadic
> templates).
>
> I would not be opposed to a more fine-grained flag that allowed you to
> disable the quirks for the processor when -fms-compatibility is turned
> on, akin to -fno-delayed-template-parsing.
So you want a default that produces the same bugs as VC++ and only a
switch will produce a standard conforming compiler. I cannot tell you
how amazing I find that and how wrong that is.
Honestly if that is the case, aka "let's just create a completely
compatible compiler with VC++", I haven't the faintest idea why clang
developers would have spent a second of their time doing that since
anybody can use VC++ instead.
>
> ~Aaron
>
More information about the cfe-dev
mailing list