Re: [boost] Boost and clang under Windows

Subject: Re: [boost] Boost and clang under Windows
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-09-29 13:40:04

On 9/29/2013 1:21 PM, Andrey Semashev wrote:
> On Sunday 29 September 2013 12:59:27 Edward Diener wrote:
>> First off I am not of course proposing any changes to the upcoming
>> release build of Boost 1.55 for clang under Windows.
>>
>> It turns out that clang under Windows, possibly to support the ability
>> to use Windows header file, becomes another compiler which defines
>> _MSC_VER. I believe the Intel compiler also does this but there may be
>> some others.
>>
>> However clang is a much more strictly conforming to the C++ standard
>> compiler than VC++ and does not have VC++'s quirks. This presents a
>> problem in Boost.
>>
>> The Boost header files have numerous places where testing the macro
>> _MSC_VER produces slightly different behavior based on the fact that the
>> code is being used by VC++ or a compiler with the same behavior as VC++.
>> But clang does not have the same behavior as VC++ despite defining
>> _MSC_VER.
>>
>> Can I go ahead and change some of these situations as necessary to get
>> clang under Windows to work properly with Boost code ?
>>
>> The usual change will be to test not only _MSC_VER but also that
>> __clang__ is not defined for keeping the current implementation which
>> assumes a VC++ compatible compiler with VC++ behavior. I am willing to
>> make those changes in 'trunk' and keep an eye out for any significant
>> failures in unit tests for our current regression tests.
>>
>> I have already made a slight change to Boost PP config.hpp on 'trunk' so
>> that clang for Windows will pass the preprocessor tests. I am willing to
>> work on other changes but I do not want to go ahead and do so if the
>> maintainers of other libraries see any reasons for me not making the
>> changes on 'trunk'. Of course I will test any changes I make locally to
>> make sure they do not affect any other _MSC_VER defined compilers as
>> well as with VC++. But the changes themselves should be fairly simple,
>> just adding a check that __clang__ is not defined as part of the VC++
>> type behavior. Obviously something like the many tests for _MSC_VER in
>> order to specify #pragma once will not change but some other situations
>> will to exclude clang from the _MSC_VER functionality.
>
> Sorry, I haven't been following the discussion about Clang on Windows closely,
> but as I understand, it is in an early stage of development, isn't it? I think
> someone said it is not able to compile even the simplest "hello world" code
> samples? If so, should we add more scaffolding to Boost in order to make it
> work with a pre-alpha state compiler?
>
> My second concern is that Clang advertise itself as an MSVC-compatible
> compiler while not being one. Intel compiler, for example, also does this, but
> unlike Clang it is pretty close. If Clang aims to be compatible with MSVC (and
> I assume it does, since it defines _MSC_VER), it has to make sure it can
> swallow any MSVC-specific code. For this reason I would prefer Boost code not
> to be adjusted for Clang, but rather the other way around. If someone is
> willing to push Clang on Windows forward, I think reporting bugs to Clang team
> is more appropriate than adjusting software for it.

The problem is that one is asking clang to dumb itself down in order to 
be compatible with VC++. It may do this just enough regarding Windows 
header files but it may be too much to ask it to do this in regard to 
Boost header files. Windows header files may have non-standard C++-isms 
in them which clang can fairly easily adjust to since the Windows header 
files hardly implement much of C++.

Remember that Boost hopes to create code which is standard C++ 
compatible in implementations which are on the cutting edge of C++ 
implementation. The clang implementation is on the cutting edge of the 
C++ standard. Boost only chooses workarounds for compilers which do not 
follow the standard in some respects. Asking clang to dumb itself down 
to accept non-standard implementations in Boost because _MSC_VER is 
defined is much more radical than asking clang to accept Windows headers 
files.

I would still much prefer that we make the adjustments for clang under 
Windows in the Boost header files than asking clang to adapt to some 
VC++-ism ( essentially adding erroneous C++ code to their very 
conformant C++ implementation ) which is not standard C++, simply 
because _MSC_VER is defined by them in their Windows build. The changes 
we would ask them to make for Boost, to support C++ non-conformance 
under Windows, would almost certainly be far greater than what they may 
have had to do to compile Windows headers.