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]>
> 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.
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk