On 3/7/2017 12:12 PM, Niall Douglas via Boost wrote:
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.
Your mention of VS2015 Update 2 above led me to think it was some downloadable software available for that product. Now I realize that it is available for VS2017 currently being launched. So much hubbub for a product which is just now being officially made available has confused me. I have this bad habit of waiting until some software actually officially exists and can be used before I become interested in it. Excuse me <g> !
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)
Thanks for all the info !
Niall