... I am sorry, but that's very untrue.

As it happens, not every language is implemented using runtime written in C/C++, nor does every language modules written in C/C++ to extend it instead of FFI.

Dealing with libraries written in C++ without C API is one of the worst PITAs in my experience, leading to crazy things like KDE's SMOKE (which, to make it funnier, has bad documentation, so I'm still unsure if I can make it work outside Qt's object model)

> ... I am sorry, but that's very untrue. > > As it happens, not every language is implemented using runtime written in C/C++, nor does every language modules written in C/C++ to extend it instead of FFI.

You did an awesome job tearing apart that strawman, but you are misrepresenting what I said. That second sentence is in no way in conflict with my "very untrue" statement.

To refresh, with emphasis added for the reading impaired:

    C++ actually makes binding to *a lot* of higher level languages a lot nicer than doing so with C.

That you can find a distinct subclass of languages where you believe that it is hard to do bindings to C++, doesn't mean the above statement is even mildly untrue, let alone very untrue. Please review and reconsider:

* There are certainly a lot of higher level languages which don't qualify for your definition. * SMOKE is actually a binding through Qt's MOC, which is generally considered by the C++ community to be something which makes Qt pretty un-C++-ish. You are right to phrase it as "Qt's object model", because it sure as heck isn't C++'s.

Try looking at the LuaBind and Boost.Python libraries. They represent a very different approach to language binding, and it isn't dependent on there being a wrapper C API. While writing binding framework for a given language is a bit of a PITA, once that has been built, it really does make binding to a high level language a lot easier than trying to do it through a wrapper C API.