Hacker News Reader

Comment by kentonv | Hacker News Reader

You can do that with C++ too -- assuming they are conforming to the platform ABI. On Linux, for example, all C++ compilers can call each other's code just fine.

You may be thinking of the funny situation on Windows where GCC has historically flagrantly disregarded the platform C++ ABI and implemented its own instead. I assume this decision was made as a matter of practicality: The Cygwin people didn't have the resources to try to implement Microsoft's ABI, whereas porting over the existing code for the Linux C++ ABI was a lot easier. Also, MSVC tends to take much longer to implement new C++ language features than GCC does which means its ABI could often be missing things GCC needs.

FWIW, Clang's port to Windows is taking the correct approach: they're implementing Microsoft's ABI, and will thus be able to link against MSVC-built C++ library. http://clang.llvm.org/docs/MSVCCompatibility.html

View on HN

GCC didn't ignore the Windows C++ ABI. Windows doesn't have a platform C++ ABI.

Microsoft consider MSVC's C++ ABI as being internal to the compiler. They don't guarantee that the ABI won't change between major versions, only that it won't change between minor updates. Either way, it is not considered to be part of Windows, unlike the C ABI.

It's also not completely documented, so you'd have to reverse-engineer most of it if you wanted to be compatible.

It's the platform's de-facto C++ ABI, certainly, and in practice it's somewhat stable, but hardly reliable or useful for anyone other than Microsoft.

Other compilers and platforms used to have the same problem - each compiler had it's own ABI, and on platforms where one compiler was dominant, it basically became the de-facto standard, but there was no interoperability. That changed when pretty much every compiler (aside from MSVC) and OS (aside from Windows) adopted the Itanium C++ ABI, or a derivitive (like the ARM C++ ABI).

The C++ standards organization have a draft proposal to have platform standard ABIs, specified and documented by the platform holder. This really only affects Windows, and would require Microsoft to define a C++ ABI for Windows. That would most likely mean documenting the MSVC ABI, and calling that the standard C++ ABI.

Various Microsoft employees are pushing for it, so it might happen. The proposal was written by Herb Sutter, for example.

Hmm, you got me. I had thought MSVC's C++ ABI was documented and intended to be used by other compilers, but sounds like I got that wrong. Still, as you say, it is the case that most other platforms do in fact have a C++ ABI (if belatedly).

In all fairness, Microsoft breaks abi in the standard library with every single release. They do so deliberately to reserve the right to improve implementations over time.

For some evidence:

See an interesting reddit thread: http://www.reddit.com/r/cpp/comments/13zex3/can_vs2010_c_lib...

And a link to a msvc blog post which lists the sizes of various containers under various versions of MSVC: http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.a...

Note that vector<int> on x64 shrunk from 48 to 24 bytes between VC9 SP1 and VC11. That's not an ABI, it's source compatibility.

True, but that's a different level of ABI. Stefan is talking about the base language ABI, e.g. calling conventions, vtable layout, etc., which is what matters if you're trying to call C++ from another language. You're talking about the ABI of the standard library -- or, more accurately, any library that uses STL types in its interface (which probably disqualifies it from being called from another language anyway).

Its worse then that! The ABI is different for debug and release version of the same library resulting in crazy, crazy bugs.

Reply on news.ycombinator.com