Everyone loves to bash the lack of a C++ ABI. Now please name another language with native implementations with a standard ABI across different compilers.

C implementations have a standard ABI, because they usually are the operating system ABI.

I'm not sure what you mean here by "name another language". Do you mean other than C? I don't understand what that would demonstrate.

For example, Lisp, Scheme, Ada, Modula-3, Delphi, D, Go, Oberon don't have compiler implementations that produce object files compatible across vendors.

Usually you are only able to link to libraries compiled with the same compiler. The same way as it happens to C++.

That it's not that common?

No, because language standards only specify the language itself not the implementations.

So each vendor comes up with its own library format and tricks how to make the language usable in dynamic libraries. And as far as I know, they seldom talk among themselves about common ABIs.

C ends up being used as universal ABI, because in the end all implementations that generate native code need to interface with the operating system, which usually is developed in C.

But this was not always like this. Before C won its place as system programming language outside the UNIX world, there were other systems programming languages in use. On those systems there was no C ABI as such.

The Pascal calling convention ABI exists, because on the early 80s a few operating systems were developed in extended version of Pascal, like the first MacOS, for example.

We love to bash it because it's shit.

Also, to answer your question: Java, C#/Mono.

Ok, there you have a point, thanks to the bytecode as ABI.

I forgot about that, as I was thinking about compilation directly to native code, as I wrote my comment.

It's also much easier to specify a C abi. You don't have to worry about name mangling, exception propagation, inheritance relationships, templates etc.

That's what I thought too, until I found that there exists C++ ABI on linux. I tried to link together two small files, both using iostreams, one compiled with Intel C++, the other with g++, and it worked.

Though I'm in doubt [haven't tested it yet] whether it would have worked had I tried to use something std::vector across functions compiled with different compilers.

It is less of an issue in linux where there is a healthy ecosystem of libraries where you have access to source code and can reasonably expect to be able to compile everything with the same compiler. (Obviously there are times when this is not practical, but for most cases, it is ok).

Under Windows, the whole situation is a mess.

For current interesting platforms, the problem is often solved by either having no C++ compiler, or just one (e.g. the Qualcomm QDSP, which I think only recently gained a C compiler lacks a C++ compiler, and I don't imagine this changing soon).

clang uses the same ABI as gcc and if you find that something is binary incompatible then it is a bug.

Actually this is mentioned by "Rhythmic Fistman", but the post only got 6 points.

From a purely practical standpoint, the lack of an ABI is the #1 reason I don't bother with C++ anymore because chances are pretty good that I'll want to interface the lower-level code with something like Python or Go, both of which integrate with C code much more easily than C++.

This is exactly the problem with C++ today. C++ "wants to be on top". Unlike C, it makes for a very uncooperative lower layer for other languages to build on. Unlike C, it's difficult to build up component libraries in C++ that can be easily used by the rest of your code. C++ makes more sense if you're writing your entire application in C++ but that's just way too much hassle for most applications.

Linux and *BSD have a fixed ABI for C++.