Boost logo

Boost :

Subject: Re: [boost] [build] How to use with clang on windows?
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-03-27 09:13:20

On 3/27/2016 6:50 AM, degski wrote:
> Hi Edward,
> I don't know what you mean by Clang/LLVM and Clang/C2.
> I wrote this earlier: "There are two usable versions of clang targetting
> VC, the (main) difference is in the back-ends, one has the LLVM back-end (
>, the other the C2 back-end (
> The Clang/LLVM compilers Clang-Cl.exe, Clang.exe and Clang++.exe are al
> just copies of the same file." If you read John top-post you'll see he also
> refers to those two different compilers.
> By "targeting" on Windows I mean that clang is built to use either the gcc
>> RTL or the VC++ RTL. The version which targets the VC++ RTL has a VC++
>> conforming non-standard C++ preprocessor while the one targeting the gcc
>> RTL has a C++ standard conforming preprocessor.
> Targeting Windows and GCC (RTL) are two mutually exclusive notions. I guess
> you are referring to MinGW. although it works, one can hardly call it
> targeting windows

An executable built with mingw(-64)/gcc runs natively on Windows, so
your comment above makes no sense.

>, it's a usefull workaround for things that won't work
> otherwise ((like compiling OpenBlas.lib f.e., as there is no free native
> Fortran compiler on Windows, but this has issues, like obligatory dll's
> instead of static libs).
> They are two distinctly different implementations.
> Sure.
>> No !!! Why should Boost support a non-conforming C++ preprocessor when a
>> perfectly good conforming preprocessor is available from clang for anything
>> which does not target VC++.
> Boost is already supporting the non-conforming C++ preprocessor.

It's hard enough supporting the non-conforming VC++ preprocessor. I
personally have no intention of supporting another non-conforming
implementation of the C++ preprocessor in clang's 'emulation' of VC++ in
Boost PP or Boost VMD. If you or someone else wants to do it, go ahead.

>> Try running Boost PP with a VC++ conformant preprocessor without the VC++
>> workarounds in Boost PP and you will find more issues than you can imagine.
> Sure, but there's no compelling reason to try and do that.
> Your logic does not follow.
> What I'm trying to get across is that Clang/LLVM treats the VC14-STL as
> bog-standard C++ (and it works, so it must be conforming). I know this,
> because it also assumes my own code is standard conforming and protests if
> it doesn't. It flags issues in Intel's Thread Building Blocks as well f.e..
> Clang is used on Linux, Mac, and Windows and maybe a few other OSs I don't
>> know about. It only emulates VC++ when it is built for Windows targeting
>> VC++. You still don't seem to understand that in the vast majority of its
>> uses clang has a C++ standard conforming preprocessor while in a single one
>> of its uses clang has a VC++ emulated non-standard C++ preprocessor.
> Yes, I do understand that it's different. But boost is already supporting
> this different PP, as it is already supporting VC. The Clang team is doing
> the work here. I get your frustration, but in practice I don't see an issue.

The issue is the huge amount of work involved in supporting a
non-conforming C++ preprocessor such as VC++ in Boost PP and Boost VMD.
The answer to that is not to create another different non-conforming C++
preprocessor, which you then want to be supported in Boost PP and Boost
VMD, but to have organizations like Microsoft and clang adhere to the
C++ rules for preprocessing code. Clang actually does follow the C++
rules for preprocessing code in all respects except when it 'emulates'
VC++. Microsoft has never conformed to the C++ rules for preprocessing code.

> Feel free to offer "workarounds" in Boost PP and Boost VMD to deal with the
>> clang targeting VC++ 'emulation' because I know I will not be doing
>> anything to get that 'emulation' working in those libraries. I have already
>> been down that path with VC++ itself and will not be repeating that
>> experience with another broken C++ preprocessor.
> I've been looking at the approach John takes in the top-post and got a bit
> futher than he did. I'll answer to his post with my findings.
> Have a good day,
> degski

Boost list run by bdawes at, gregod at, cpdaniel at, john at