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 15:32:45

On 9/29/2013 3:00 PM, Andrey Semashev wrote:
> On Sunday 29 September 2013 13:40:04 Edward Diener wrote:
>> On 9/29/2013 1:21 PM, Andrey Semashev wrote:
>>>
>>> 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.
>
> This has nothing to do with Boost being the cutting edge of C++. It still is,
> whether or not it supports a particular (non-mainstream) compiler on a
> particular platform.
>
> If Clang aims to implement C++ and not MS extensions/bugs then it shouldn't
> pretend to be MSVC. As simple as that. GCC went that route, even though it
> still implements some MS extensions (but notably not bugs). IMHO, that would
> be the simplest and probably the right way.
>
> As for now, Clang pretends to be MSVC, so it should pretend better. This
> includes implementing extensions (__declspec, intrinsics, __intXX, pragmas and
> what not) and probably some fundamental shortcomings. It might also require
> various compatibility modes with different MSVC versions. They provide a
> Visual Studio plugin, so the user is able to use Clang as a drop-in
> replacement for MSVC. And this means the user is "allowed" to feed his
> MFC/COM/DCOM/ATL/DirectX or whatever other Windows-specific code to it, not
> just windows.h. I'm not requiring things like managed C++ or AMP, since these
> things are more dialects of C++ than C++, but nevertheless, if Clang supports
> them as well, this will be an additional plus.
>
> I admit, the latter approach is surely less pleasant for Clang team, but if
> they define _MSC_VER for nothing they will simply make things much much harder
> for developers. Intel took this approach and please note that Intel compiler
> does implement more of C++ than MSVC does, but these features are disabled by
> default.

I totally understand your viewpoint. But if we assume that _MSC_VER with 
clang is strictly VC++ in Boost, and it is turned on in the default 
usage of clang when using Boost Build under Windows, then it is nothing 
but VC++ as far as Boost code is concerned and therefore offers none of 
the standard conformance as a compiler which clang as a compiler is 
noted for. Therefore, as far as using it with current Boost headers 
under Windows to test/compile Boost code, it is totally useless AFAICS 
since using it is using VC++.

>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>