Re: [boost] [clang] How to use CLang for Windows?

Subject: Re: [boost] [clang] How to use CLang for Windows?
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-09-29 19:26:17

On 9/29/2013 5:43 PM, Beman Dawes wrote:
> On Sun, Sep 29, 2013 at 4:06 PM, Edward Diener <eldiener_at_[hidden]>wrote:
>
>>
>> With all due respect, Beman, there is no point of doing this at least for
>> Boost headers once I reverted the fix to the Boost PP code that would have
>> allowed clang under Windows to correctly compiler Boost PP code as a
>> strictly conforming C++ standard preprocessor. It fails miserably as the
>> VC++ preprocessor and I am not personally interested particularly in
>> discovering why since the VC++ preprocessor is just badly broken in a
>> number of respects general. To emulate that brokeness cannot be the goal of
>> any C++ compiler.
>>
>
> IIUC, they are aiming to support the aspects of VC++ that are required to
> compile and run the libraries shipped with Visual Studio and libraries like
> Boost. I doubt they intend to mimic bugs not required for that purpose, and
> they have stated up front that they intend to support all C++11/14
> features, not just those supported by VC++.

If they don't intend to "mimic bugs not required for that purpose" then 
the fix I put in Boost PP config.h is absolutely necessary. Please try 
"bjam toolset=clang" in the Boost PP test directory under Windows after 
building or installing clang under Windows. You will soon understand why 
I made the change I did. After the slew of failures that you see because 
clang, a highly comformant C++ preprocessor pretends to be VC++ for the 
purposes of the Boost PP code because it defines _MSC_VER, you can make 
the change I originally did and try "bjam toolset=clang" again in the 
Boost PP test directory. Then you will see the difference.

I do understand and applaud clang's purpose to compile code properly 
under Windows, even using the Windows header files. But I do not see the 
purpose of emulating VC++ when it is broken in regards to the C++ 
standard if it is not necessary. My Boost PP change made emulation of 
the broken VC++ preprocessor unnecessary for Boost PP. Please remember 
that very little other, if any at all, preprocessor code written for 
Windows is going to require clang to emulate the broken VC++ 
preprocessor in order to compile Windows code. Boost PP pushes the 
boundary of what can be done with the C++ preprocessor in a 
cross-platform way. Can it really be that clang in Windows wants to go 
from a C++ standard compliant preprocessor to the rather horrible VC++ 
preprocessor just to accomplish its goal of compiling C++ under Windows ?

Each case is distinct and there may be some other cases where clang will 
attempt to emulate VC++ but trying to duplicate the VC++ preprocessor 
should not be one of them. I cannot emphasize this more. There's no 
point in producing a first-rate product and then crippling it in some 
large respect because of emulation on a particular OS. I don't 
particularly care what else it brings to the table.

I know it is a fine line to decide what compromises might have to be 
made in pure C++ standard code to emulate VC++ and therefore compile 
Windows code. There may be other cases where clang will emulate VC++ 
even if it does not strictly follow the C++ standard. But the 
preprocessor is not one of them if you know anything at all about how 
badly VC++'s preprocessor is broken for all but the most basic macro 
expansions.

>
>
>>
>> I will wish the clang people best of luck on their Windows implementation
>> but if it means emulating VC++ in every respect I do not see the purpose of
>> it, as I can just as well use VC++.
>>
>
> VC++ is not planning to support all of C++11/14 until roughly the end of
> 2014. Clang under Visual Studio will support all known C++11/14 features
> out of the chute. Surely that is a huge win for Visual Studio users,
> whether boost developers or otherwise. Even once VC++ catches up, there is
> a great advantage in having two compilers running under the same IDE  since
> errors resulting in hard to diagnose error messages from one compiler often
> produce easy to understand error messages from a different compiler. It
> also makes it faster to tell if an error is a compiler error or a user
> error.