http://blogs.msdn.com/b/vcblog/archive/2015/12/04/introducing-clang-with-microsoft-codegen-in-vs-2015-update-1.aspx
To make it easier to develop cross-platform code that works well for both Windows and other platforms, we’ve released an additional compiler toolset for Visual Studio called Clang with Microsoft CodeGen. This compiler uses the open-source Clang parser for C and C++, along with the code generator and optimizer from the Visual C++ compiler. This lets you compile your cross-platform code for Windows using the same Clang parser that you use for other targets, while still taking advantage of the advanced optimizations from the Visual C++ optimizer when you build for Windows. Because the new toolset uses the same Clang parser used for non-Windows targets, you won't need to have annoying #ifdefs throughout the code just to account for differences between the compilers. Also, your code can take advantage of language features that are not currently available in the Visual C++ compiler, including C99 complex types and C++14 extended constexpr support. And because the Clang-based compiler generates the same debug information format as the Visual C++ compiler, you'll still be able to debug your code with the same great Visual Studio debugger experience.

Code compiled with the new toolset can be linked with other code compiled with the Visual C++ 2015 C and C++ compilers. Typically, you would compile the cross-platform parts of your code with Clang with Microsoft CodeGen, and compile any Windows-specific code (e.g. your UI) with the regular Visual C++ toolset.

Note that Clang with Microsoft CodeGen is currently a preview feature.

Интересно, но пока не пробовал.

Тривиальная программа компилируется. Попытался скомпилировать кусок реального проекта — падает от наличия precompiled headers. Пока фича на стадии альфы.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Интересно, но пока не пробовал.

вопросы от чайника:
1) переваривает ли clang #include <windows.h> ?
2) при include <vector> возьмется прежний vector или какой-то специфический под clang ? (vector взят для примера)

Здравствуйте, swingus, Вы писали:

S>Тривиальная программа компилируется. Попытался скомпилировать кусок реального проекта — падает от наличия precompiled headers. Пока фича на стадии альфы.
это ограничение описано

Precompiled headers are not currently supported so you must disable their usage. Failure to do so would usually manifest itself in an "error : cannot specify -o when generating multiple output files". If you still see this error even with precompiled headers disabled, please make sure that the value of "Object File Name" property is reset to its default value "$(IntDir)%(filename).obj" in Clang toolset.

Known Issues in the First Preview
...
PCH build is not supported. Turn off PCH usage for any project where you explicitly set this new Platform Toolset

Насчёт <vector> STL говорил, что пофиксил нескольго багов для clang, да и <windows.h> уверен, тот же используют, иначе нет смысла.

Здравствуйте, uzhas, Вы писали:
U>вопросы от чайника:
U>1) переваривает ли clang #include <windows.h> ?
U>2) при include <vector> возьмется прежний vector или какой-то специфический под clang ? (vector взят для примера)

Здравствуйте, uzhas, Вы писали:

U>1) переваривает ли clang #include <windows.h> ?
U>2) при include <vector> возьмется прежний vector или какой-то специфический под clang ? (vector взят для примера)

эта штука предназначена для того, чтобы разработанные под другие ОС программы портировать в винду, включая их при этом в инфраструктуру msvc (отладчик, профайлер, линкер и т.д.). соответственно, если у тебя уже есть некая виндовая разработка, то ты не совсем target audience

когда-то я пробовал под виндой clang версии 3.5 or so — мелкие программы компилировались без проблем, большие (т.е. включающие всякие stl/windows.h/...) — вылезали проблемы. при этом afair clang использует header файлы из компилятора, поверх которого он ставится (mingw/cl) — и даже с mingw большие программы откомпилировать нельзя было; думаю с cl было бы ещё хуже

раньше смысла в clang/win не было вообще — c++14 можно было олучить от mingw, оптимизация в gcc опять же лучше. с этим проектом смысл появляется, так что можно ожидать что они активней займутся виндо-совместимостью, и со временем stl/windows.h таки заработают

Здравствуйте, BulatZiganshin, Вы писали:

BZ>когда-то я пробовал под виндой clang версии 3.5 or so — мелкие программы компилировались без проблем, большие (т.е. включающие всякие stl/windows.h/...) — вылезали проблемы.
я тоже имею схожий опыт, отсюда и родился вопрос

BZ>с этим проектом смысл появляется, так что можно ожидать что они активней займутся виндо-совместимостью, и со временем stl/windows.h таки заработают
вопрос как раз в этом: есть ли какие-то качественные изменения в сабже.

Здравствуйте, uzhas, Вы писали:

U>вопрос как раз в этом: есть ли какие-то качественные изменения в сабже.

будем пробовать. но как я понимаю, front-end в чистом виде от 3.7, так что его можно посмотреть даже без установки сабжа

Здравствуйте, uzhas, Вы писали:

U>я тоже имею схожий опыт, отсюда и родился вопрос

инфа для размыщления:

Technical details: Clang 3.7 shipped with a couple of options, -fms-extensions and -fms-compatibility. -fms-extensions controls non-Standard features like __declspec(dllexport), which the STL requires to get its job done. -fms-compatibility controls "bug compatibility" (i.e. making Clang imitate C1XX bugs), but when David and I met at CppCon 2015, we realized that there are two kinds of bug compatibility: bugs that affect ABI (e.g. layout) and bugs that don't affect ABI (e.g. accepts-invalid). So there have been changes committed to Clang's post-3.7 trunk (and ported to the Clang/C2 release). Now, ABI-relevant bug compatibility is always enabled when targeting Windows, as this is required to be link-compatible with C1XX/C2 binaries. ABI-irrelevant bug compatibility is controlled by -fms-compatibility. Our STL's headers (and tests) now work with -fno-ms-compatibility, the strictest level of conformance. (There's one minor exception: <future> drags in <ppltasks.h> which was doing something non-conformant although fairly innocuous. The Standard doesn't permit incomplete classes to be returned by value, even from "imaginary" functions that are declared but never defined. By the time I discovered this, it was too late to get a fix into Update 1, so Clang/C2 was temporarily hacked before releasing in order to accept this specific thing. I've fixed <ppltasks.h> for Update 2, so the Clang/C2 workaround can eventually be removed.)

Здравствуйте, BulatZiganshin, Вы писали:

BZ> -fms-extensions controls non-Standard features like __declspec(dllexport), which the STL requires to get its job done.
то есть они переваривают стандартный студийный STL

вот тикет от 2012 года, где видно, что уже тогда они переваривали windows.h : https://llvm.org/bugs/show_bug.cgi?id=12283