Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp

Subject: Re: [boost] Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp
From: degski (degski_at_[hidden])
Date: 2017-03-27 00:11:44

On 26 March 2017 at 09:39, Peter Dimov via Boost <boost_at_[hidden]>
wrote:

> LLVM Clang finds and uses the 14.1 headers for me when using the
> clang-linux toolset. I could tell because it gave me errors in these
> headers when I wasn't supplying -fms-version=1910.
>

It seeems to me that that was not was intended. But having said that, if
clang-linux works (with the Dinkumware STL), then progress is definitely
being made and we're moving towards having just clang-any (on the 3 major
platforms). I (and I guess I'm not alone) really appreciate the work (by
yourself and others) that is being put into this!

> clang-win is outdated.

Yes, it's lagging, but I would say the only benefit is the better debugging.

> Clang under Windows is more or less the same as Clang under Linux now,
> except that it targets the Microsoft ABI (and fails to link).

Don't know about linking, must be a path problem or something to do with
the clang-*linux* bit (ELF?). I'm using Clang/LLVM (from the VS2015 IDE) on
a daily basis, no issues.

> Visual Studio 2017 doesn't use clang-cl.exe, it understands Clang's
> options natively and uses clang.exe.
>

Great, cannot wait getting back home from Central-America to Central
-Europe, so I can give it a try, as hotel WIFI is flaky here. Are you
talking about Clang/C2 or Clang/LLVM?

> A proper clang-win toolset today would treat Clang as Clang, not as
> cl.exe, only it would replace the link phase with a working one.
>

+1

> And a proper clang-c2 toolset would do the same except it would use
> 14.0/14.1 as the version and look for clang.exe at the appropriate
> locations.

If Clang/LLVM works as any Clang, the only difference should be the
backend. Obviously, one can only hope for this to work with VC14.1(0) or
higher...

degski