It is called COM/UWP on Windows.

A C++ ABI requires an OS written in C++, likewise there is no such thing as C ABI per se, rather UNIX ABI, Win32 ABI and so forth.

A C++ ABI does not require an OS written in C++. It just requires all compiler implementations to agree to standardize on a single ABI and enshrine it in a spec that any future implementations must abide by.

A C++ compiler that needs to support multiple distinct ABIs?

One per each platform, plus an additional one, agreed by all these guys? And the list is not 100% compliant, e.g. TI is missing.

https://en.m.wikipedia.org/wiki/List_of_compilers#C++_compil...

Not even C has managed to do it, what people conventionally refer as C ABI is actually the OS ABI.

I still remember having to deal with multiple C ABI on MS-DOS and Windows static libraries.

I'm really interested to know how a standard ABI would cover both little endian 32 bit x86 and big endian 64 bit POWER.

Compilers already have ABIs, they're just compiler-specific and not documented. If they didn't have an ABI, then you couldn't link 2 C++ libraries together.

In terms of having one spec that handles arbitrary architectures, maybe it could be defined relative to the C ABI? I don't actually know how what the internal ABIs used by the current crop of C++ compilers looks like, so I don't know if they could be expressed relative to the C ABI or not.

Alternatively, one could come up with a set of configurable values that define what makes one architecture different from another (such as word size, long/pointer size (if different than word size), endianness, etc). You know, the stuff that the compiler already has to know about in order to compile for an architecture (and I'm pretty sure clang at the least already has a way to even define new target triples in terms of a set of configurable values for this sort of thing). I assume existing compilers don't invent entirely brand new ABIs for each new architecture but instead just adapt an internal standard C++ ABI to the new architecture using a similar process already. The same could be done for a public standard C++ ABI.

Pardon the dumb question, but is the term ABI new (or experiencing a recent increase in usage)? I've seen it twice in the last 24 hours, and never before in my life. And that's despite being entirely too familiar with COM.

> but is the term ABI new

No, it is age old. The thing is that it is only "a thing" to embedded native developers and library authors.

The general concept is that the programming language "API" doesn't define how the dll/o/a/la/lib/so/dylib "loader" look for "symbols" in the file. If you example, I do:

    enum {FOO, BAR};

and next month I change it to

    enum {BAZ, FOO, BAR};

then everything will still compile, but if I execute an older program with my library, it still thinks FOO is 0 and BAR is 1 while it's no longer the case. It gets worst for function and type definition. Then when you get into C++, it gets an order of magnitude more complex because almost every code change will somewhat break one or many symbols. This is why there is often "proxies" called PIMPL or d_ptr between the library symbols and the actual implementation code. C++ has no officially standardized way to serialize the object to their symbol names. This is often a pain point and Apple wants to fix this for a decade for has so far failed to get everybody to agree on something.

For embedded devs, more problem arise from the fact that the instruction set and C library themselves are not the same for all devices and this also break pre-compilled code.

Many platform will often favor "static binaries" over dynamic ones to avoid the consequences of breaking the ABI.

I think you see it because there has be a resurgence in interest in C/C++. probably because people are giving up on the idea that all new languages will run on the JVM.

ABI is ancient since it defines the underlying structure that allows you to link compiled object files and liberals together (the latter both statically and dynamically). Allowing code generated in one module to successfully call functions in another.

> Allowing code generated in one module to successfully call functions in another.

That's not quite true. That's already possible without a standard ABI.

What's not possible is to get code compiled by a specific compiler to call modules built by another compiler provided by another vendor. That's the only problem that is addressed by a common ABI.

I would also add that considering MS's interoperability history and how prevalent MSVC++ is, working on a standard ABI would be a waste of time.

> What's not possible is to get code compiled by a specific compiler to call modules built by another compiler provided by another vendor. That's the only problem that is addressed by a common ABI.

Yes, compilers need to agree on the ABI, the platform ABI, that is. Today most platforms already have a de-facto or de-jure standard ABI and compilers have the option to implement it.

Even if such a thing was possible, there is no value in the standard committee standardizing an single ABI as most platforms would never break backward compatibility to switch to it.

No, it is an old term.

Yes, an ABI would be great. I am always amazed how easy it is to use libraries in C# or Java whereas C++ is just a PITA.

That's possible because all C# and Java compilers only really target a single platform (their respective VM).

It is easy as well, when you use a compiler that generates bytecode like C++/CLI.

Ummmm... Try running java 8 bytecode on an older JVM.