These languages can use C fairly easily. To use C++, you must wrap the C++ interface in `extern "C"` interfaces. It's very hard to use the full spectrum of C++ features.

Consider that you're writing a custom struct/data type called MyStruct in your language. Now, can you use std::vector<MyStruct>? This requires your other language to read the entire vector header and instantiate a new type based on both your definition of your custom type and the vector template. The vector instantiation will ask questions like whether or not your type is copy constructible and move constructible, and if so, use these implementations. Designing this into your other language requires a lot of compromises.

And that's just templates. ADL poses an even bigger difficulty. Again when you write your custom type in your language and define a swap function for it, will C++ standard algorithms that need swapping find your implementation via ADL? Recall that swapping is invoked via having `using std::swap;` and then invoking the bare function `swap` which triggers ADL. Again, designing this into your other language requires a lot of compromises.

The only language that I know of that comes close to having full interoperability with C++ is Objective-C, and it does so by creating a new Frankenstein language called Objective-C++. It has two different kinds of classes, two different exception mechanisms, etc.

Wrong, D has support for C++ FFI.

https://dlang.org/spec/cpp_interface.html

It supports neither templates nor ADL, the two of my examples.

In fact the doc says,

> Being 100% compatible with C++ means more or less adding a fully functional C++ compiler front end to D. Anecdotal evidence suggests that writing such is a minimum of a 10 man-year project, essentially making a D compiler with such capability unimplementable.

It then goes on to describe the pragmatic approach that doesn't allow full compatibility:

> D takes a pragmatic approach that assumes a couple modest accommodations can solve a significant chunk of the problem:

> matching C++ name mangling conventions

> matching C++ function calling conventions

> matching C++ virtual function table layout for single inheritance

Can you see how limited this subset of interoperable API is?

> matching C++ name mangling conventions

> matching C++ function calling conventions

> matching C++ virtual function table layout for single inheritance

Basically COM? Which is not surprising as it was designed as an OO native FFI.

And UWP improves on it, giving more C++ features across the ABI, basically what .NET v1.0 should have been all along.

I didn't state it supports 100% compatibility, and it is still better than being stuck with an OS ABI from the 70s, that is only meaningful when the underlying OS is written in C anyway.