Re: [boost] Boost and clang under Windows

Subject: Re: [boost] Boost and clang under Windows
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-09-29 15:00:44

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.