Hacker News Reader

Comment by revelation | Hacker News Reader

I'm a bit confused about how this will work exactly. If I have Clang and VC++ compiled code trying to interop with each other, what happens if Clang decided to use a different memory layout for std::string (or any other type really) than VC++? What compiler is doing which task in the pipeline here exactly?

I mean, the reason everyone does interop strictly in C is that there are zero standards for how a compiler implements the C++ features exactly down-low.

View on HN

Clang has, for some time now, supported the MSVC ABI.

Here is their implementation of name mangling: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Micros...

Here is their implementation of record layout: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Record...

Here is their implementation of vtable generation: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/VTable...

Here is their implementation of RTTI: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/Mi...

Here is their implementation of C++ throw metadata: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/Mi...

That's nice, I wasn't aware that they were working on this specifically.

This was not done by microsoft at all :)

But none of that was written by Microsoft employees, so I'm a bit confused about what exactly this blog post is announcing. It feels a bit like they're taking credit for the work done by the clang community.

We are announcing that we will ship a hybrid compiler that combines the clang frontend with the c2 existing backend. We will fully support that for building portable code within Visual Studio for Windows. We definitely don't want to take credit for the clang community's work. We have a ton of respect for those developers. We intend to make contributions back to the community and we've started to reach out to some of the relevant parties. Thanks, Steve, VC Dev Mgr

To be clearer, "Here is their implementation of ..." should read as "Here is clang's implementation of ...".

AFAIK, Microsoft hasn't contributed to any of these ends. I, for one, hope that they do.

As I understand it, it's not bringing Clang/LLVM's libc++ to Windows. The memory layout of, for example, std::string isn't decided by the compiler - it's decided by the library/header files. Both Clang and MSVC would be using the same MS C++ header files, so the only thing up to the compiler would anything that isn't specified in the header files, behind the scenes.

We're already using Clang with msbuild on Windows for native C11 support (come on, Microsoft!), courtesy of pre-built Clang for Windows binaries [1] - using the Microsoft C/C++ headers and linking against the Microsoft C/C++ runtimes.

There's already a plugin for MSVC that makes the Clang toolset available. VS 2013 (or maybe it was 2012?) decoupled the MSVC build chain/toolset from the IDE, making it possible to swap out which toolchain you're using from the project properties. Actually, it may have even been VS 2010, because I was using it to compile with ICC, but then again, I remember having a hell of a hard time so perhaps it was VS2012/2013.

1: http://llvm.org/docs/GettingStartedVS.html

correct, this will use MS libraries. If you watch Jim Radigan's Build talk (he owns C2), he talks a little bit about how the ABI is really a part of the platform and it might clarify some of this. http://channel9.msdn.com/Events/Build/2015/3-714 about 23 minutes in. Thanks, Steve (vc dev mgr)

Clang was already planning on using MS libraries/headers.

IE this is literally not different from what was already being done, without MS :)

yes, we are well aware that clang and llvm is working on targeting windows. this is clang+c2 which we will fully support.

"The memory layout of, for example, std::string isn't decided by the compiler - it's decided by the library/header files."

Not quite true. Different compilers can decide to do different alignment/padding. It should be fairly simple to make clang and MSVC avoid that scenario, though.

Also, they must have taken care to use the same ABI and C++ name mangling rules in both compilers. I would guess Microsoft's version of clang follows MSVC here, so that one can link clang code to existing third party libraries.

It's not easy to mix two different versions of code compiled with different microsoft compilers, or even with the same compiler but different settings.

Reply on news.ycombinator.com