Sounds like a nice project, I did not want to insinuate that the quality is not good, I did not used Qt in a few years(since Qt4 days) so I am not sure about QML, without doing any research I think I am inclined to use the classic QtWidgedts for a desktop applications, SQML seems to me more mobile or designer first toolkit.

I strongly believe that Microsoft made a huge mistake not making .Net WPF and Silverlight cross platform and open source it. they would have made money by selling the Visual Studio IDE,

does it work with .net core? i.e. linux?

Primarily it's due to function overloading. Different implementations may use different means to consistently and uniquely "mangle" function names on symbols to uniquely identify them in the library export. This mangling depends upon numerous factors, including parameter types and calling convention (if there are multiple conventions on a platform).

I think it’s because of name mangling (to enable polymorphism).

Name mangling wasn’t originally standardized, so every compiler did it differently, and now it’s too late to standardize.

The other commenters so far have blamed name mangling. Name mangling isn't actually that big of a deal: to mangle most functions, just write out the fully-qualified name of the function/method, convert each component of the name individually via a simple function, and then tack on the mangling of the types for every argument. Name mangling can get hairy, but realistically, you're not going to be linking against a template using an unnamed lambda as a parameter.

The minor complication you get is that the C/C++ ecosystem uses char, short, int, long, and long long to determine types, while most other languages use a more sensible i8, i16, i32, i64 system. This means you can't use the native type system of your target language as the base for mangling, since i32 and i64 do not map cleanly to int, long, and long long. (Doesn't help either that pre-stdint.h libraries for defining target-independent i64 types may have chosen a different value for i64 than stdint.h).

The real problem is that a lot of the functions you would wish to call don't actually exist in the binary library you're linking against. Inline methods are frequently excluded as linkable targets, and you often don't want to link to them anyways, because they're meant to be inlined (think something like std::vector<T>::operator[]). On top of that, templated things are rarely instantiated (and have code generated for them) until their point of use).

Because it's so flexible, low-level in some parts (memory management, raw pointers) and high-level in others (template metaprogramming, lambdas).

If you restrict the API to a subset of the language, you can make C++ ABI just fine. My favorite style is abstract interfaces.

For the GUI example, look at WinRT. It exposes very high-level functionality, expressed in C++ as IUnknown-derived interfaces. These interfaces can be consumed or implemented by any compilers, or even other languages.

Such APIs work well even for very performance-critical code like DirectX or Direct2D. But there's downside, such APIs is not the most idiomatic form of C++: no exceptions, no iterators or other template shenanigans, no RTTI, no standard collections not even strings. All that stuff needs to be replaced with some equivalents.

When I only have C++ clients, I don't usually inherit from IUnknown, instead making an abstract base class with virtual destructor, and using std::unique_ptr smart pointers instead of CComPTR.

It has been done already: https://github.com/woboq/qmetaobject-rs