<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Aug 26, 2014, at 10:50 PM, Nikola Smiljanic <<a href="mailto:popizdeh@gmail.com">popizdeh@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">I'm not sure if this has changed since clang-cl was introduced but resulting clang depends on what you build it with. I'm sure this will go away at some point if it hasn't already. Compiling clang with mingw produces a mingw compatible clang that uses libstd++ and ld. Compiling it with Visual Studio would produce msvc compatible clang that uses msvc stl and link.exe. I think the main difference comes from the triple where something like i586-win32-pc defines a different abi from i586-pc-mingw and passes -fms-extensions -fms-compatibility and some other stuff to indicate msvc compatibility. Have a look at <a href="http://clang.llvm.org/docs/MSVCCompatibility.html">http://clang.llvm.org/docs/MSVCCompatibility.html</a><div>
<br></div><div>clang-cl is supposed to be a drop in replacement for cl.exe and as such accepts same command line options and enables language extensions and/or bugs :). The same way clang/clang++ are a drop in replacement for gcc/g++. But there's nothing preventing you from using the compliant version of clang on windows, it's just a matter of what flags are being passed to the driver.</div>
<div><br></div><div>Then there's also the idea of the complete clang toolchain on windows (libc++, lld, lldb) that many people would like to use. But the question of default ABI for this toolchain still remains. I can't find the thread but I remember someone pointing out that just because Microsoft owns the platform it doesn't mean that their compiler's abi should be seen as the default one. But if Herb's proposal for C++ ABI is accepted it will mean exactly that, the platform defines the abi... </div>
</div><div class="gmail_extra"><br></div></blockquote></div><br><div>What I would hope is possible is to be able to specify on a per-translation-unit basis to compile the unit in a completely normal fashion, but get microsoft symbols in the .o files OR compile the unit with with the microsoft-spcific adaptations. That way, some units could depend on Windows.h and Win32 and others could depend on libc++ and behave as I would expect on every other platform. If I can do that then I can contrive a shim layer to adapt insulated Win32 code to work with any standard c++ code that I want. </div><div><br></div><div>I always structure my projects so that most of it is standard c++ with an insulated platform-specific later…even if I don’t immediately need to have the code cross-platform.</div><div><br></div><div><br></div><div>-James</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></body></html>