Boost logo

Boost :

Subject: Re: [boost] [regression runner] Preference libstdc++ vs. libc++
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-03-07 17:12:07


On 07/03/2017 16:48, Edward Diener via Boost wrote:
> On 3/7/2017 9:47 AM, Niall Douglas via Boost wrote:
>>> The problem with clang targeting the MSVC ABI, as far as Boost is
>>> concerned, is that it erroneously implements the non-standard VC++
>>> preprocessor. This makes it all but useless for using with Boost. That
>>> it should have even been designed to do this for all macros, rather than
>>> just for the macros it needed when processing VC++ and Windows headers,
>>> is its major downfall. When you have to emulate something that is
>>> already non-standard, and for which no internal knowledge is available,
>>> you are already on the wrong path.
>>
>> You can tell C2 clang to not use MSVC compatibility and VS2015 Update 2
>> and later's headers will now compile cleanly. I would assume VS2017 is
>> the same.
>
> Where is C2/clang available for download ? It seems the only thing that
> is not mentioned in the C2/clang blogs. Nice going Microsoft !

In the VS2017 installer, you just choose C2 clang just as you would any
other component.

I can't remember if Visual Studio's default project settings turn on
MSVC compatibility, but if they do, turn it off. Bar newly introduced
bugs in the headers (ping Stephan on those), C2 clang is compiling the
Windows SDK headers fairly well without MSVC emulation. There are some
warnings at -Wall though.

Note cmake et al don't understand the new path locations in VS2017 yet
and it's a pain. HOWEVER you can now load cmake projects straight into
VS2017 whereupon they find the new toolset because VS2017 ships a custom
cmake internally. It's incredibly slow though, almost unusably slow. And
VS2017 in cmake mode gets very badly confused frequently i.e. it's buggy.

(Before someone from Microsoft asks for me to report the bug, let me
suggest to you to go install WSL and try running cmake-within-WSL on the
same project as VS2017 has loaded via cmake. It's a disaster, and a real
impediment to the whole point of cmake project loading, you need to add
some logic to account for concurrent cmake-outside-of-VS2017 especially
when that is Linux cmake not Windows cmake)

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk