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 16:18:20

On Sunday 29 September 2013 15:32:45 Edward Diener wrote:
> 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++.

Not totally useless, but less useful than a fully conforming implementation, 
alternative to MSVC. That's why I would prefer Clang not try to pretend MSVC 
in the first place.